3. We don't currently have the systems and structures in place for successful open-source governance.
Those are just big words, what do they mean? I explained why (and how) AmigaOS development could continue exactly like it did IMHO - what are those "systems and structures for open source governance" we allegedly need and why do we need them?
Fair questions. I've been thinking about this sort of thing for a few days.
this 2006 article from Sun Microsystems is a little old but has some good points, getting into the merits and pitfalls of open source. Bear in mind that he's speaking about large, corporate-backed open-source efforts; we'd need something appropriate to the scale of our tiny community:
I believe the biggest challenge for an open source community is to understand in what ways governance will impact its community members. Governance is critical to an open source project. While open source licensing lets people have access to source code, this doesn't have to mean that chaos ensues. In fact, open source projects are typically very well organized and are run with a great deal of professionalism and discipline. Governance helps ensure that the people running the project can decide what gets incorporated into the source code.
There are one or two open source communities that really don't seem to have good governance. The lack of good governance leads to a loss of freedom for the people that use the software. Good governance lets open source communities decide upon standards, and good open source standards are implemented by multiple software products leading to the long-term sustainability of all of the software.
<snip>
There isn't a single one-size-fits-all approach to governance. Different communities have different needs, but there are also attributes that are essential to good governance — like meritocracy, transparency of process, and open access for everybody with the necessary skills to participate in a project. How governance gets structured really depends on the organization. For example, governance of the Apache Software Foundation is quite different than the governance of the GNOME Software Foundation. Both organizations are very meritocratic, but the Apache approach is very formal, while the GNOME governance model is more relaxed. Both are exemplars of good governance.
<snip>
Sun would have open sourced Java a long time ago. But open sourcing commercial software is more than just picking a license. Existing developers need to be respected. And, it's important to figure out how the governance of the project will respect the contributors. There are also issues about proving relicensing rights — not to mention producing an environment in which a well-designed and backwards compatible implementation of the Java platform can be kept in the marketplace. So, Sun isn't delaying. Sun is figuring out which license will work best, devising governance, reviewing copyright ownership and so on.
I've also been looking at
Apache's and
Mozilla's governance practices.
Fundamentally I'd say it's a combination of institutional management, project management, and community management. The professionalism and discipline cited above are key. We need (1) user- and developer-backed decision makers to set long-term goals and priorities of individual releases, we need (2) community liaisons to stay on the pulse of user needs and to be the first line of communication so that (3) skilled developers can focus on executing the roadmap for a given release.
Community buy-in is absolutely critical at every stage, but part of our challenge is that we probably have as many opinions in the community as we have users
The professionalism and discipline are essential in the process so that everyone's opinions are respected, even if some people's opinions aren't adopted verbatim. That's how we prevent (further) fragmentation.