Managing Open-Source Projects

Reading: Producing Open-Source Software

See social.pdf, from Matt Butcher.

Who will be in charge of the open-source project? Who will decide what pull requests to commit? Whoever it is does not get to decide the agenda (unless there are paid employees involved); that is set by the contributors.

As an example, suppose the Free Software Foundation created a browser (besides wget). If someone contributed code to allow the playing of DRM-protected content within that browser, the FSF would almost certainly reject it. But who would actually make that decision?

For many projects, there is a top-level "board" of sorts; a group of "founders" who make decisions like this. Governance is usually a meritocracy: maybe only contributors get to vote?

For other projects, one person is appointed benevolent dictator. A BD is more like an arbitrator, or judge, than a decision-maker; generally, lower-level participants have worked out the pros and cons of each side, before the BD steps in. A good BD need not be a great programmer, but must have a strong vision for the project.

Social.pdf has several slides on the BD role.

An individual or group that sets up an open-source project can set up governance however they wish. However, if contributors are dissatisfied, they are likely to fork. Forking is bad: it gives outsiders the impression of dissension, and it faces outsiders to choose which version to install. A large number of them will choose neither, because it's simpler.

Lessig's book "Code" contains a fair amount of material on project governance.

Some BDs:


The IETF and consensus:
(Ok, the IETF isn't exactly about Open Source, but the governance is similar.)

Dave Clark:
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.

Jon Postel:
Be liberal in what you accept, and conservative in what you send.

Postel and crypto: is there a real conflict here?

What if consensus cannot be reached? See ietf64 (not online).
Voting! But who gets a vote?



Mission statements

Communications

Archived email is ubiquitous within the IETF. One common problem is that many contributors don't know where the archive is. Slack is another approach.

Most open-source projects show a strong preference for asynchronous communication: no video chat, for example. (That said, the IETF actually has regular f2f meetings, at which IETF workgroups may meet as well.)

Rules for email (communications.pdf)

Communication.pdf (Butcher) has some examples. See also POSS, You are what you write. Also POSS, Content, Tone, Recognizing Rudeness and Face.

See also ietf64.

And don't forget lkml.org.

Avoid bikeshedding (though this is not limited to open source). See POSS, The Smaller the Topic, the Longer the Debate.

Remember: in Open Source, you cannot just cut off a debate by managerial fiat.

Avoid Holy Wars. Typically these start about

Toxic contributors:

toxic.pdf (notes from Matt Butcher)

Producing OSS chapter 6

POSS, Nip Rudeness in the Bud