I once worked for a company that was over 20 years old but felt like a startup (in terms of policies and procedures, and how things got done).
There are a lot of similarities between that company and how we do things here - and there are certainly advantages to having a structure that’s not entirely coherent, because you have a lot of flexibility.
But with that amount of flexibility comes uncertainty and confusion, and bringing new people into that environment is very challenging, as we’ve experienced - even knowing how to get started can be a big hurdle.
I think a governance structure around the project needs to strike a balance between the flexibility of “anything goes” and being too rigid in what is/isn’t allowed. From some informal discussions, for example, the idea of a technical steering committee is something that perhaps is seen as undesirable for various reasons, including (ultimately) the lack of flexibility in letting people “scratch their particular itch” and having it be part of the project as a whole.
I think there’s merit to that point of view. At the same time, there’s also, I think, a need to have some mediator/arbitrator about how the project does things so efforts aren’t duplicated. I don’t see that role as the same as the board’s role in dispute resolution (but maybe it isn’t), which I see more about community disputes rather than technical disputes.
Linux kernel development seems (in my view, not that I’ve really looked closely) to have the flip side of that - they have Linus and others like Greg K-H who act as technical “final deciders” about what gets included and doesn’t, but there isn’t much in the way of a formalized mediation structure for non-technical disputes (maybe because of the nature of that project, the disputes tend not to be non-technical).
Our project is a much broader scope, obviously, than the Linux kernel is, so the needs are different. But perhaps we need to start with looking at our charter before getting into governance.
Closest thing to a charter that I’ve seen on the website is this:
The openSUSE project is a worldwide effort that promotes the use of Linux everywhere. openSUSE creates one of the world’s best Linux distributions, as well as a variety of tools, such as OBS, OpenQA, Kiwi, YaST, OSEM, working together in an open, transparent and friendly manner as part of the worldwide Free and Open Source Software community.
(From openSUSE Wiki)
That first sentence is really the summary itself, and it’s extremely broad - maybe too broad. It lacks information about scope, objectives, resources, roles, and responsiblities. (Timeline is often used in project charters, but how that would fit for something this large is a bit different).
It may be fair to say that openSUSE isn’t a “project” in the “PMI” sense of a project, but more like a “program” (a collection of projects that are coordinated together), but even in program management, there’s more than a single declarative sentence that defines what the program is about - that structure helps define what the elements of governance are.
If we start with:
The openSUSE project is a worldwide effort that promotes the use of Linux everywhere.
And then answer the question “How does it do this?” (which the second sentence perhaps attempts to answer, but also is too much of a summary), maybe that gets us started.
Or maybe we take that high-level answer and break it down into more specific, defined, and (dare I say) measurable goals, and that would help us get to what we need in order to start building governance around those objectives.
