Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on an open source project that has full time professional developers from several universities, plus a couple of other organisations. The product has something like a dozen deployments, various variations, plugins, related components etc. Generally development so far has been driven by institutions "scratching their own itch", but with an effort to merge improvements back to a central code base.

As it's starting to mature, I'm interested in possible models of open source governance to follow. (So this question isn't "what are some good things to do", it's specifically "what existing, tested models are worth looking at and possibly following")

Specific aspects that such models might cover:

  • How decisions about big-impact changes are made (and what happens if someone makes big changes without discussing them first)
  • Who manages the product's public image (product marketing, for want of a better term)
  • Who represents the product in any comparisons with "competing" products
  • Whether enhancements become "core", "plugins", "related products" etc
  • Whether and how roadmaps are created and published
  • How variations on the product are handled (in this case, versions for different academic disciplines)
  • Expectations and obligations of participants in the project
  • Expectations and obligations of the institutions for which those developers work

We'll be looking for something as lightweight and informal as practical.

share|improve this question

A good structure would be to have several lead developers (maybe one from each university/org) manage a repository that is easy to manage and control (GitHub is a good choice). Contributor releases would be done as pull-requests and then accepted by the lead developers. There should be some basic rules posted to avoid debate. An example rule would be that releases must have tests or require evidence of how the code was tested. Those rules should be published in the ReadMe.

A contributor or lead could be named the "marketing guy" and submit pull requests to the ReadMe and updates to the Wiki and be responsible for the roadmap, etc.

For versioning use a standard as much as possible that conveys minor changes versus breaking changes. Semantic versioning is a good model that is increasingly accepted for open source project.

Variations can be handled as branches and/or private forks and GitHub makes this easy as well. This post discusses a nice model for branching using Git.

This may be too specific on the tooling but certainly these tools have been successful in maintaining many open source projects that are highly collaborative with multiple contributors.

share|improve this answer
Yep, we're already using Github and pull requests. The link for semantic versioning looks useful. – Steve Bennett May 25 '12 at 0:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.