How Open Source Communities Work

Several happenings over the weekend are case studies in how open source software communities work.

The Dev Behind a Hugely Popular GNOME Extension Just Quit

While the news is about a developer quitting because it’s not “fun”. I think the message – or messages – are deeper than that.

  1. Isn’t it awesome that are free software is developed by people that love doing it? Back when I started the OpenLogic Expert Community, I contacted many maintainers and offered to pay them to fix issues that our customers had. Some of them turned me down because they loved working on open source software and thought payment would change that. (That inspired my Would You Do It Again for Free? talk.) Some of them turned down payment because this was a hobby and if they got payment their family might view it and the time they spend on it differently. They took free tech goodies instead!
  2. Wouldn’t it be great if when what you are working on no longer made sense, you could move on to something better suited for you at the moment? Working on something you love, because you love it, gives you the freedom to say it’s no longer your favorite thing to work on and to move on. You do still have responsibilities but in this case, it sounds like there was good backup.
  3. Feedback. I do hope that the GNOME community takes this feedback as an opportunity to explore how things are going. They should survey other users and figure out if this is an individual problem or a systemic problem and how they might prevent it from happening in the future.

Canonical CEO Mark Shuttleworth makes peace with Ubuntu Linux community

It is a positive sign that the GNOME project – or this part of it – had a clear and positive succession plan.

Again I think the title doesn’t capture the importance here.

Governance is very important to every open source software project. It’s important when you set it governance to determine how councils, boards and advisory boards are going to work. Who is going to be on them? What criteria determines who is on them? What are they supposed to discuss? What do they get to decide or control? How do their decisions get implemented?

And projects evolve. You need to continue to examine the governance structure and make sure it’s still working. Sometimes advisory groups are created to raise money or to make marketing decisions. And later they start making technical decisions. What does that mean? Should the group evolve? Or is a different part of the project experiencing difficulties that this group is trying to fill in for?

While I don’t know specifically what happened with the Ubuntu Community Council, it is normal for projects to have governing structures that change and evolve over time. As they set it back up, it will be important to figure out who is on it, how people get added and removed, what their charter is and how their decisions will be implemented.