Tag: governance

Posted on

Be Clear About How Things Work (How Open Source Can Work with Companies)

This post is one of a series of posts about what open source software projects can do (if they wish to) to make it easier for companies to participate in their projects.

When a company wants to get involved in an open source software, often they need some help understanding how things work. Sometimes it’s the developer who wants to contribute that has questions. Sometimes it’s their management who wants to understand what type of commitment they are making and what they can expect.

An open source software project can make it easier for a corporate contributor to participate by being clear about:

  • What the release process and schedule looks like.
  • How long it takes for a PR to be reviewed and how to best position it for acceptance.
  • Who makes decisions and how.
  • What roles people in the project play and how they get to those roles.
  • Where and how to ask questions.
  • Who is working on the project and what their motivations are. (Is this software to make apps run faster on watches or is it to make apps run on car computers?)
  • How to find out and stay informed of security issues.

As an open source software maintainer, the more you can help organizations understand how you work and how to work effectively with you, the more likely they are to engage.

Posted on

What open source governance models are available?

If you are looking for an open source governance model, there are two resources to explore.

  1. Red Hat has published the Project and Community Governance Guidebook on GitHub. It covers things from roles of the participants, to how projects evolve (and governance should evolve with them), to policies and procedures.
  2. The FOSS Governance Collection just launched with a collection of governance docs on Zotero. It is a great place to go see real, live documents used by existing open source software projects. (If you work on an open source software project, or just notice that one is missing, please upload the governance docs!)

Don’t forget, a project’s governance needs to evolve as the project evolves.

Posted on

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.