Discuss here...

On the openSUSE Factory mailing list a bikeshed was started talking about how 'SUSE controls openSUSE' (see my earlier blog about bikesheds).

Luckily, several people were kind enough to point out how off-topic this discussion was on a developers list. And how horrible the timing was with regards to the openSUSE 12.1 release, keeping everyone from work.

But the discussion was not entirely irrelevant, as Robert noted - if people still think that SUSE somehow, magically, makes things happen in openSUSE, it's worth talking about that. Just not on a developers' list where people try to get work done!

Wrong list

If you're new to how Free Software communities like openSUSE work, this discussion is relevant. I know that the way many communities work is not very transparent to outsiders. And openSUSE is probably not the best in this area. But where to discuss this?

For the contributors to openSUSE, who have been around a while, this is no issue. So this discussion does not belong on a developers' list. If it was a widespread problem it might belong on our project mailing list. But in this case, even that is a bit overkill in my opinion. Hence this blog.

As reminder: if you start such discussions again and again on the wrong lists you will ultimately be kicked from development lists for disturbing the Force. Please don't do it!

Let's talk HERE

So, let me try and provide a more 'proper' place for this discussion: here. I'll start off with explaining how 'we' make decisions and what SUSE's role is. Feel free to ask questions or discuss this further below. And yes, it might make sense to collect the results of this discussion into a wiki page describing our 'governance' to avoid such discussions in the future. Volunteers welcome, remember, talk is cheap!

Structure

Unlike most other large distribution communities like Debian, Fedora or Ubuntu, openSUSE does not have a clear structure. We have the openSUSE Board and a release management team but that's it. There are of course groups in openSUSE - the edu team, the marketing team, translators, the boosters. But they are just gatherings of people who do a certain thing, not people who (can) tell others what to do. We have no Engineering Steering Committee or Technical Board, nor (benevolent or not) dictators, project leaders or anything else telling anyone what to do. Yes, as I've said many times before, that includes me: 'community manager' is a SUSE title, not openSUSE, and I have no say over whatever anyone of you do. Nor do I want to!

Decision making

So how DO decisions get made? Recently an interview was done with Michael Miller, who himself clearly was a bit surprised about how things worked. But, as the interview shows, he gets it now: people do what they want in openSUSE. That includes SUSE engineers - SUSE rarely tells their engineers what to do in openSUSE. Most are active as volunteers and those who are paid to do things (like myself) have a huge amount of freedom to do what they think is best for openSUSE. Robert wrote the same in a response to the initial questions. Read his mail.

It is very simple. The decisions get made by those who do the work, by consensus and on technical grounds.

Example process

Let me give an example: replacing the sysvinit boot system in openSUSE with systemd.

Who's involved in the decision to do systemd or not? Four (groups of) people:

1. the maintainer(s) of the current init system

2. whoever proposes the new solution (can be same as 1

3. The release team

4. All developers who need to adjust to systemd

Step 1. Those involved discuss and decide.
Now the maintainers of sysv init (1) and those working on systemd (2) talk together. If 1 decides that 2 has a great idea, they will stop maintaining the 'old' system and move over to systemd, together with 2.

Step 2. Release team gets involved.
They will then tell the release team, which will look at it from a technical point: will it break things? They will demand from 1 and 2 that they ensure no or very little breakage.

Step 3. Public discussion.
It is now time for the wider project, especially those who are influenced by this decision, to hear about the plan from the maintainers (systemd mail to -factory on June 2011). At this point, the rest of the distro contributors and possibly, in case a developer blogs about this, the rest of the world can also respond. Everyone can either come with additional constraints/limitations or object to the change wholesale. In both cases, they can either hope to convince the maintainers to take on the constraint or objection, or offer to solve the problem (and/or maintain the old system) themselves. Obviously, if the vast majority of the fourth group, everyone who needs to work with systemd, objects - there's a big chance the maintainers will cave. But they don't have to and if nobody else steps up to maintain the old system, well, everyone will just have to suck it up!

Note that in no way can the rest of the community (or anyone else for that matter) demand that the maintainers will listen to them. If you can't convince them with arguments nor provide an alternative with your work, well, too bad for you. This is how Free Software works.

Step 4. The decision
So yes, in the end, the maintainers decide. The release team will have the choice of not accepting their work (and how to schedule), of course, but if nobody has an alternative, that's unlikely. And the same goes for everyone else: you can vote with your work or your feet. Making noise just means the developers put your mail address and IRC nick on their blacklist.

This does not mean developers don't listen to users - they do. But they do via the channels they like to do it (blogs, bugzilla, openFATE, reading the openSUSE Forums). And in no way do they have to. Some prominent FOSS projects are maintained by people well known to not listen to users, and power to them. You're free not to use their software, so they don't have to listen! You can of course pay them, like with the Nepomuk fundraiser set up by it's author and the Krita fundraiser before that. Then yes, they will listen...

But SUSE...

No, SUSE does not control openSUSE. They do NOT interfere in this process. Remember how openSUSE picked a new release schedule? A new default desktop (KDE)? I can tell you that in both cases, SUSE management was not really convinced it was great for SUSE or openSUSE. But they did not interfere.

Obviously, SUSE, as a community member, sometimes wants things. So SUSE does occasionally tell their engineers to work on a specific thing in their paid time. Then the community can accept, or not, what these engineers do. Following the exact same process.

So if things don't go how you like them to go, well, don't blame SUSE. Blame yourself as you are the only person to blame. Because you didn't do anything about it. do, as in work, by the way, talk doesn't count as I said before. It just keeps people from doing their work but doesn't produce anything.

Discussion, questions

I agree the above is a bit opaque sometimes. We don't have a very clear list of maintainers and the process as I describe is maybe still not very clear. Even if it's clear now, it's not written down anywhere other than here. Feel free to ask for further explanations or challenge my assumptions. And volunteer to move this to a wiki page on the openSUSE wiki so we can educate newcomers better.