Originally Posted by wXR
Olaf, the beauty of open source development is that the tools (these days, at least) facilitate a kind of self-organization. Discussions around complex technical topics can be resolved with issues. Pull requests allow individual developers to submit changes, but that doesn't mean your fork gets overruled. With GitHub, you can put a project online as a maintainer who has the final say in terms of what gets pulled in. The point is it's all there for you, a model that has proven itself with tens of thousands of succesful projects at this point.
I don't doubt that Amiga development is complex, but it doesn't get any less complex without code being dissected and discussed in public, in a forum that is familiar to today's developers. If I were to say "yes" to your question about mentoring, it wouldn't matter if the code wasn't available anyway. The whole idea would be preposterous.
And of course things are a mess, but it's a mess because of both the practices around its development and the inevitable crust of time. Still, all of the toolchains can be improved. Perhaps some of them can be unified. The wonderful part is that, with an open source development model, someone can come in and improve some smart part in a spare moment, while another improves something else of interest. There is no need for a monolithic approach, though again, as the maintainer, you can reject anything you want during your code review.
Surely this makes more sense than the way things are done now. Surely a near-total industry shift to this model for everything except games and appallingly dangerous IoT devices tells us that this is something that works?
Personally I don't care who owns the so-called "rights" to AmigaOS, but if that bothers some folks, and/or makes it harder to collaborate on GitHub, then perhaps we shold simply look at collectively buying out these rights, once and for all? Why not pool our energies a bit and liberate them to the Internet, as should have been done 20+-odd years ago already.
Hum. I do don't reject the idea that process has improved over the past 22+ years. AmigaOS 3.5 and beyond were created using CVS and lateron SVN (why not Git? AmigaOS source code layout is very peculiar in how individual components are versioned, and that fits CVS/SVN better than Git; also, there's no Git for AmigaOS), it would have been murder to stick to RCS.
We used mailing lists for communications, we had a bug tracker (still do), we had a beta test team (still do) and a method to securely distribute updates. All of that is more or less a solved problem. Some people might suggest that things could be so much more productive by moving the whole show to cross-development instead of native development, plus the latest toys (e.g. GitHub, Jira, what have you). I doubt that.
The problem isn't so much with giving developers access to the operating system, including the tools to collaborate. The tools to create software with, and to test it with, as available for AmigaOS are about 20 years old, in some cases even older.
I'm groping for some sort of metaphor to illustrate what this entails. It's hard, but I'll try: imagine that development on the Linux kernel stopped in 1993 and did not resume until yesterday. Whoever wants to pick up the baton now has to figure out how to recruit collaborators who know something about the IBM-PC hardware platform, the CPU architecture, who know which tools (compilers, linkers, etc.) might be useful to get software development for the platform working again. People who know how to work together until the team jells, who don't throw up their hands and walk away when things get difficult.
This is the big challenge: "priming the pump". AmigaOS 68k development has been "suspended" for almost 20 years. How do you get it started again?
I'm reasonably certain that it could be done. My concern is that we lack the very fundamental resources required to build upon. For example, there's just one single working source level debugger for the Amiga, and it's about 23 years old. That sort of thing puts real fear into me.