Okay, let me clarify: You don't like having your little babies open sourced.
Did you look at my github page? There is open source there. If you look in Aminet (hey!), you'll find sources of MuFastRom, and some other of those tools. In source form. There is, erally, open source, though for a different, more disciplined community.
You were against open sourcing P96 - which would have been a tremendously good thing for the Amiga - now you're maintaining it. You are against open sourcing AmigaOS - and you 're the one developing it. I can see a pattern here.
Huh, what? I'm not developing it. I don't know who is, all I'm doing is that whenever I see a bug, I fix it, but that's hardly development. If you want to know who develops it, ask Jens. If you want to contribute, ask Jens. He's probably looking for someone to drive his product because I cannot.
What does any of this have to do with AmigaOS?
A *lot*, because that is exactly what makes the difference. We do not have a critical mass of developers, we do not have sufficient numbers of commercial players.
Current situation: Your team develops AmigaOS 3.2. Releases it. Doesn't get paid. Then works on 3.3.
Other than that, there will be only superficial differences between both scenarios, like Cosmos starting a flame war telling people how much your coding skills suck and releasing CosmOS 3.2, and everybody laughing about him.
You're just trying to distract from the simple truth that in reality, nothing much would change by open sourcing AmigaOS.
A lot would change, and I'm really stunned that you don't see that. We would not have one version of AmigaOs, but multiple. It would be hard to develop any software for anything beyond 3.1 because there wouldn't be a stable ground for it. "Works with library Y, but only from distribution A, not B". It would be hard to get hardware developped for it - "needs ROM from X, not from Y". I'm really stunned that you don't see the difference between "here is the documentation, here is how it works" and "oh well, here is a bunch of software, make your pick, and if it doesn't work, well, wrong combination, but not my problem".
We would have a "KollaOs - motto - I know it better anyhow", and "SpeedGeekOs - but my Os is 0.5% faster than yours", and whatever other stuff. Currently, already about 30-40% of development time is wasted in compatibility issues by products that are written in an inable way. We have a couple of workarounds even in 3.1.4 to keep DOpus happy, to keep Kingkong happy, and others. Now, multiply this by the number of distributions to expect, and we're in a situation where Os development becomes blocked by just hunting down such issues.
This kinna works in Linux because there is a sufficient critical mass to handle such problems, but we have a much smaller bunch of developers. To be able to keep development possible, we need to cut *down* the complexity, not increase it. This program was already started with 3.1.4 (only *one* utility.library, only *one* graphics.library). How would that work with "just another exec" from "we don't do autoconf because we know better" or "just another graphics because we know how to save two cycles from an inner loop". Thank you, there are lots of other more important things to do, and I don't want *my* time wasted with a lot of useless dicussions with people that do not know better, despite what they want to make you believe.
Are you seriously mentioning "many desktops would arise" and "we would loose consistent look and feel" to tell us how bad open sourcing AmigaOS would be? Have you actually ever used AmigaOS? Do I need to make a list of available desktops, docks and taskbars for you? Or GUI toolkits and Gadtools/ASL patches?
See above. Now tell me, how is this going to improve with this complexity even on the Os level? How can we handle this complexity? Who can? How to create software on unstable grounds, without development power available to handle the additional complexity?
You forgot to mention that open source AmigaOS also abuses his wife and beats his children.
Say, do you want to be taken serious or make a fool of yourself?
We've always had quasi branches of AmigaOS or parts of it ever since Commodore went down. People were patching their systems to death, installing (allegedly) faster serial drivers and Workbench replacements or replacing major parts of the system with backports from AROS. Guess what? We survived it. And so did AmigaOS.
For which definition of "survive"? It made the whole game tremendously difficult, as a couple of these "creations" are road-blocks for particular developments. Are you seriously saying that the situation is going to improve by creating more roadblocks?
We would still have rules. You're the only one claiming otherwise.
Which rules? Once it is open source, the ghost is out of the bottle. "Fuck rules" is probably the only rule I would know from this community.
And If I were a developer relying on "the rules" as defined by you, I'd have started to use Reaction as a GUI toolkit when 3.5/3.9 were released. Then I would have switched back to Gadtools (?) when 3.1.4 came out, now I'd have to rewrite my projects again to switch back to Reaction.
Reaction on your system didn't went away, just we couldn't support it for reasons you know precisely. I'm all happy we can continue to support it now. Nobody was expecting you to rewrite a project - quite the opposite, the interfaces should remain as stated.
So how are 3.1.4 and 3.2 developed? Who's making the decisions?
The wrong people. Developers, like me. Surprised? That's exactly why we need a better process. I'm all for opening up the process, just we couldn't do. We do have RFCs, though not as consistent as I would like, though publishing those would be nice, and having a forum for collecting feed back would be helpful, just someone to filter them because it is just too much for us to handle, and to filter out all the trolling. A bug tracker would be helpful, for the public. Most importantly, end user support would be helpful, because we're definitely the wrong people for that. We would also need people with experience in human interface design, which is badly lacking.
But there is a difference between "open source" and "open processes", "developer driven" and "design driven". Prime example in Amiga land "how to get it wrong" is DefIcons (which caused a lot of trouble and discussion inside the development crew, and also because I'm pretty bad at this as well). It is a nice software architecture, a good data structure, a good abstraction of the search process as a tree, so software-wise, Stephan did a good job - and at the same time, the whole way how its preferences look like is over the head of its users, and the prefs are a binary blob that is impossible to handle without an editor, and hard to adapt and unflexible. A UI to handle its preferences is as charming as the Windows registry editor.
I'm not saying that Stephan back then did a bad job, really not, but he started from the wrong end. But it was, as far as the UI is concerned, not the right software. It was developer driven. I created a lot of internal struggle and fighting to get away with this model and get something simpler and easier to handle, where you just drag your default icons into a drawer, and create the rule files, encoded in ASCII, with a simple Wizard program. So it is scalable, and easy to handle. That caused a lot of trouble and misunderstanding, also due to my un-ability to communicate correctly, yet, I believe strongly that the result is much better and much simpler and much easier to handle and to adopt. The software architecture is probably less "nice", but the result is hopefully a lot more accessible.
I'm not so good at all this as I should, but if you look around, there is a reason why Apple became so successful: It is *exactly not* a developer-driven process, but a UI-driven, design-driven process. That is, in a sense, a good example why open source "is good for developers" is a bad way of designing a system that should be usable by the average guys.
So you're saying it would be better for AmigaOS if Ben and Timothy would call the shots instead of you?
I would say that AmigaOs would be better if we had a specialist in UI design (and not a lawer) who would be central in decision making, yes. What we would need is a management that believes in its product (and not its money it may or may not make). Hyperion is a "company" and not a company because of exactly that. A management with a clear vision is missing, and a mechanism to implement its vision and communicating this vision to the developers. That is missing. You do not get this in the open source world - and then you deliver things like "Gnome3" or "cups". Nice software, bad usability.
I would be hoping that by creating a board that makes decisions, with developers having voices, but also management defining a direction would be a good thing. I would be hoping that the board would be transparent in decision making and communication.
You know, there are good reasons why we have a representative democracy, where - ideally at least - elections allow people to chose between various visions, though representatives care about the details how to implement them. It does not mean "everybody has the freedom to do everything" but "make your choice, but trust the decision makers to do the right thing to respect your vote". Well, at least in theory.