27 October, 2011

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!

Your point is irrelevant! I refuse to listen!

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!

Welcome

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. steps

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.

Question Everything

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.

10 comments:

  1. Well Jos,

    Given my recent experiences with the openSUSE board, I highly disagree!!!!

    There is a member of the board who is a SUSE employee who does make top-down decisions that impact contributors to the openSUSE project.

    ReplyDelete
  2. Sure, a technical mailing list is the wrong place for such a discussion. But using a blog's comments is not a lot better, since it's seemingly random where this discussion is happening, most people will miss it, and blogs simply do not provide the structure needed for important discussions.

    opensuse-project seems to be a better place, but then, who is still reading that, with a signal-to-noise ration as high as the sky?

    Maybe it's symptomatic that the discussion started on the wrong list ... ?

    ReplyDelete
  3. @greg be specific or don't say anything. Vague accusations aren't exactly up to your own standards, I would say. Frankly, even I don't know what you mean :D

    @sebas Yup, you're right, this ain't the prefect place. But I think it's only relevant for a few people and I mostly want to (work here to) document it and/or have a place to point people to.

    And yes, bikeshedding seems to be moving from -project to -factory because people simply have left -project and the bikeshedders (incl topic starter) notice that. Which means we have to be a bit more strict in moderation (a moderator has stepped into the tread which started this blog post, btw).

    ReplyDelete
  4. google "opensuse factory" -> http://en.opensuse.org/Portal:Factory -> Learn how factory is developed -> http://en.opensuse.org/openSUSE:Factory_development_model

    Everything you say is documented :-)

    ReplyDelete
  5. I think the most important point to remember is that although some SUSE employees (such as myself) are active in the openSUSE project, we are in the role as openSUSE community members. We are expected to be self-sufficient specialists, able to manage ourselves and set our own goals. There are no strings controlling our actions in the project; our actions are determined by our own immersion in openSUSE culture and wider Free Software culture through our pasts as volunteers in FLOSS projects or our years working on SUSE Linux.

    This independence is hard to grasp from outside SUSE - it's always easy to see organisations as opaque, unified blobs that move mostly according to some plan. But our only brief is to make the openSUSE project succeed and enable everyone to contribute. As an employee it can be frustrating; compared to traditional proprietary software companies with top down decision making it can take a long time to build a consensus to achieve something. From an employer's perspective, it also seems counter-intuitive - management is letting the cats run wild in the belief that in the resulting tangle there will be something useful to construct products, and a vital and respected SUSE brand to sell them with.

    So maybe it's better to think of us less as employees but more like community members with a lot of experience and specialist skills who happen to be fully sponsored by SUSE - much like Aaron Seigo is sponsored by QtDF/Nokia to contribute to KDE, with 100% autonomy.

    ReplyDelete
  6. @Henne - yes, the factory model is there but talks very much in terms of top-down decision making ('escalation' and the like). It also lacks an example and focuses on technical decisions.

    The process I am trying to describe is more of the generic way of working - it works similar in -artwork. I probably should not have taken a technical example ;-)

    I think I'll try and make the Factory page include something along the above lines about generic decision making in our project, instead of creating a new one.

    ReplyDelete
  7. Thanks Jos for wording it again and like this.
    Thanks to Will I believe you exactly describe how it should work, wait it's already tje case for those of us who work.

    ReplyDelete
  8. sir,
    I have HTC Verizone windows mobile. I would like to know does my phone supports fm radio software (India) ? If so, how do in install on it ?

    regards,
    Sudarshan

    ReplyDelete
  9. TED Talk: Daniel Pink on the surprising science of motivation

    http://www.youtube.com/watch?v=rrkrvAUbU9Y

    Watch till the end.


    This talk pretty much describes WHY FOSS works so well in many cases. Just read a bit b/w the lines and you will see what Jos was talking about from a bit different perspective ;)

    Hmm, might be this video is worth a separate post on the Planet? Just to make sure everyone have seen it...

    ReplyDelete

Say something smart and be polite please!