Open Governance Roles and Responsibilities

Published Friday May 20th, 2011
13 Comments on Open Governance Roles and Responsibilities
Posted in Open Governance, Qt

Last week, in my blog on the Maturity Level List and in the previous week’s Maturity Levels, I left some indications of what would be expected of a maintainer of a portion of the Qt codebase. In this blog I’d like to explain a bit more what’s expected of people working via the Qt Open Governance, what roles will exist and what responsibilities will each have.

In short, there will be three levels only:

  1. Contributor
  2. Approver
  3. Maintainer

The presence of a “Chief Maintainer” is not exactly a fourth level. More on that below.

Outside inspiration

For the Qt Open Source project, we set out with an idea that we wanted a very flat, very simple structure. The discussion on the mailing list was quite interesting, as we had in the beginning a top structure called a “board” or “oversight committee” (some early material I prepared included the recommendation: find a cheesy, non-sensical name out of a spy movie or series, like “Directorate”, “Oversight”, “Headquarters”, etc.) But in the end we decided to replace this and focus on existing examples of successful, large Open Source projects.

The two we mostly looked at were WebKit and the Linux kernel. There are benefits and drawbacks to both and we don’t think either would apply as-is. For Qt, we wanted to combine the best practices of each. We wanted to use the trust networks and use distributed development, but keep the number of hops between a new contributor and the code being in the final repository quite low. We also have a very aggressive regression testing and continuous integration system, which puts strong emphasis on quality.

The model I’m presenting here was discussed for a long time, but eventually it took one long IRC session between myself and Robin Burchell to put the ideas on paper. We posted all of our conclusions to the opengov mailing list then adjusted a little as the discussion required.

The Qt model

So we settled on basically two roles in addition to the contributor, as you can see in the drawing.[pyramid] The Contributor is anyone who has the will and skill to contribute to the project. I should also point out that contributions come in many forms, not just code, but that’s what I’m focusing on here. The Contributor starts the process by doing the contribution over a code review tool we’ll make available and use ourselves too for our own work (more on the tool on another blog). Once this contribution is in, anyone can make comments, offer opinions, suggest improvements, etc. It is not necessary to have achieved any higher level to participate.

The next level is the Approver, which matches WebKit’s reviewer level. The Approver is a Contributor who has been given the right to approve a contribution for integration into the source code. Along with that right, he/she has the duty to ensure that the contribution follows certain guidelines, both quantitative, objective (the “Technical Fit”) as well as qualitative and subjective (the “Spirit Fit”). The Approver also has the duty to be constructive when offering suggestions and even when rejecting. To become an Approver, a Contributor must basically earn the right, by making contributions and proving that he/she has the best interest of the project at heart. An existing Approver should nominate, another Approver second it and, provided there are no objections, the rights are given.

Rights easily given are also easily taken away. Approvers are expected to act in the best interests of the project, regardless of their work affiliation. They are given the approval rights over the entire codebase, but they are expected to exercise them with care, concentrating on the parts where they have knowledge about. Abuse is punished by the community by revoking those rights — in my experience of Open Source projects, this happens very, very seldom.

In most circumstances, this is all there is to it. A contribution is made, reviewed by one or more people, an Approver, who may or may not be one of the reviewers, approves the contribution, and then the continuous integration system should take it away, test and integrate into the codebase. This is where we are supposed to be very close to the WebKit model.

So where does the Maintainer come in? Well, the Maintainer is a respected member of the community who knows quite well the code in question. Unlike the Approvers, the Maintainers are tied to the code. A Maintainer basically has one duty and one right to the particular codebase he/she’s maintaining:

  • The duty: ensure that the codebase is always ready for beta. That is, ensure that all contributions coming in are in the proper state to start the release process at any time (tested, stable, feature-complete, documented, API reviewed, etc.), ensure that the code is in that state all the time.
  • The right: set future direction, reject contributions not following that directive (including removing code already approved because it isn’t stable or finished), etc.

Along with those, there are other duties, like knowing what projects are happening in that module, offering advice to people who want to contribute new features to that module and ensuring that all contributions are reviewed (so they have to review if no one else does). Moreover, Maintainers are the people whom QA and the Release Team will contact in case something is wrong.

As the codebase grows, the need for new Maintainers will appear, so we always keep a healthy number of them. That is, we should have as many Maintainers as are really required to execute the job comfortably — but no more. It is my expectation that whenever that happens, there will be a natural candidate for Maintainer: someone who is already mostly doing that job of counselling and oversight of the codebase. Another case for a person becoming a Maintainer is when the previous one is no longer doing the job properly, either because of lack of time and/or interest, or because the actions being taken are not in the best interest of the project.

Maintainers can, of course, delegate. As an example, imagine QtCore is a module and it has a Maintainer. This person may delegate all of the Tools and Containers subsystem to a person of his trust, while he/she focuses on another part of the module. It’s important to note that this is a trust-based relationship: the actions of the sub-maintainer reflect on the Maintainer. Big modules like Qt 5’s “qtbase” will have several maintainers dividing the work.

The Chief Maintainer is not to be understood as a fourth level in the structure. The Chief Maintainer is a Maintainer like the others (we’re expecting this to be the Maintainer of the “qtbase” module, in fact). Instead, this person should be regarded as primus inter pares: a person whose opinion matters a great deal to the project, due to past and present contributions. Therefore, this person is accorded the right to break bigger stalemates and make overarching decisions. This person is recognised as such, which is why we’re singling him/her out here.

You may be asking who will be allowed to fill in those roles. They are all open to anyone who shows merit, deserving to be in that capacity, regardless of work affiliation. However, when we go live, we will “bootstrap” the model with the people who are already working on Qt: that is, the Trolls and existing contributors. The names of the people should come naturally, but to be on the safe side we should allow for an adjustment period. Also, it’s clear that the “bootstrap” will include mostly current Nokia employees. As time progresses, we expect non-Nokians to join in and participate, earning responsibilities.

A final note on other roles: the above description is really focused on the code workflow, which is what happens for virtually every Open Source project out there. But in addition to the above roles, there will be many other roles to make the project tick, like the QA team, the documentation team, the Release Management team, Community Management, communications and web presence, roadmapping and planning, etc. Each of those teams will probably work with just two levels: contributor and team lead (similar to the Maintainer), unless they choose otherwise. The people from Nokia currently executing those roles will be present at the Qt Contributor Summit, so we invite those interested in collaborating to talk to them and organise sessions during the summit to suggest ways of working together.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Open Governance, Qt

13 comments

Peter Kümmel says:

This sounds very good and promising! A nice step after “We’re not there.”.

But an important question remains: Who has the power? Is there a democratic process to find a maintainer or are they Nokia-given? Is Nokia also a “primus inter pares”. (I know they pay the bill)

This is very important because Nokia has too much contact to the “dark side” and it is not clear if Nokia could overcome the temptation.

Thiago Macieira says:

@Peter: what power? The power is vested in the community. And this is most definitely not a democracy. It’s a meritocracy. Show merit and you receive the rights that go along with it. And also note what I said about there being exactly as many Maintainers as there needs to be. It means that a Maintainer position will not be created just because some company is investing X amount of money.

Sure, Nokia will be the biggest representative in the beginning. That shouldn’t be an impediment though.

Peter Kümmel says:

I only wonder about the process for the Maintainers. Who makes them to Maintainers, who decides this?

Thiago Macieira says:

The community. Usually, the people working in that particular area. What I said:

It is my expectation that whenever that happens, there will be a natural candidate for Maintainer: someone who is already mostly doing that job of counselling and oversight of the codebase.

@Peter: note that the role of maintainer is strictly a technical one, there’s no real dark-side powers that come with this, it’s just a recognisance of that person’s abilities in the given area(s) basically.

That is, it’s something that already happens naturally, without any given title: people tend to ask other people’s opinions when touching code they don’t know for help, and they will always naturally gravitate towards the people who know that area best. This is just putting that sort of method of working down on paper, so it is obviously clear to everyone, right from the start, whether they are new to the project or not. Perhaps this helps? 🙂

Anon says:

Cool, it’s like Jedi council 🙂
Who defines the “Spirit Fit”?

Thiago Macieira says:

@Anon: as usual, “the community”.

We’ll provide with the first Vision, Goals, rules for the technical and spirit fit. After that, it will be up to the community (which includes Nokians) to update them.

Lex says:

Great developer role hierarchy. Moved me to write a post celebrating you guys 😉
http://lexfridman.com/blogs/research/2011/05/20/open-source-software-engineering-is-not-communism

This is such a challenging subject for the solitary coder (such as myself) to wrap the mind around, so thank you for the good ideas.

DJ says:

Could you give us a check list which should be considered before submitting a contribution?
Could you illustrate some practical examples to show how to contribute and how it is approved?
Thank you !

Thiago Macieira says:

@DJ: sure. We’ll do that in upcoming blogs.

Anon says:

@Thiago, thank you for your reply.

I appreciate what you have been doing and what you are going to achieve and I also would like to share few opinions about the open source governance model. First, I don’t have too much experience of open source projects but i have often considered those to molded from individualist and somewhat anarchist point of view, but certainly there is also business oriented aspects that are quite common now days. Coupling these perspectives might not be so straight forward. It’s good to have structure but same time when making structure it also puts people in different positions. If for example I read that pyramid strictly, it would say that contributors does not interact with maintainers and maintainers don’t contribute? Would it better to just focus on people interactions rather than creating hierarchies or at least turn it upside down. Quality is everybody’s responsible, not just dedicated maintainers; in the sense every contributor is also co-maintainer.
Cheers -A

anon2 says:

@Anon: Roles is such setups are usually not tied to individuals. An individual can have different roles depending on the time of the day, phase of the moon, part of the code affected etc. I would not assume that the idea is to prevent maintainers from contributing actual code.

Daniel Molkentin says:

@Anon:

>If for example I read that pyramid strictly, it would say that contributors does not interact with maintainers and maintainers don’t contribute?

That’s not reading strictly, that’s your (strict) interpretation, because you are trying to find semantics in the diagram that it does not (intend to) describe.

Anon2 is quite right. Sometimes a maintainer might write a patch (and have it reviewed by someone else). A maintainer who doesn’t do any coding in his own domain is usually not a good choice for a maintainer :-). Also, contributors will interact with maintainers, either in their role as maintainers or because a maintainer is also a reviewer.

The bottom line is: This picture does not serve as a complete interaction diagram. What you should take away from it is that there are way more contributors and reviewers than maintainers. The higher you are in the pyramid, the more the more work you will probably have, because you will have to assume all the roles below as well.

That very much reflects our ways of working within the Qt organization today (so it’s not an “anarchist pov” at all :). A maintainer is just a normal developer, except he just happens to know the module very well, either because he has written it or picked up maintenance.

Commenting closed.

Get started today with Qt Download now