Open Source software - software govberned by open source license - could be developed in a closed setting
open source project - development effort built on certain principles
- peer review
- leadership rather than control
- leadership based on reputation and results
- collaborative development
"hybrid models" - open source projects that merge with employent settings and management structures - e.g. Netscape/Mozilla
Fostering community development
open source projects are widely varied - nothing that says "here's how you have to do it" - there are a set of examples of what has worked.
There must be a community of people who believe in the leadership and want to work with you.
Somet things lead to success:
- transparency - the ability to get critical information to a publicly accessible locale and keep it relatively current. It's a hard change of habit for many. Different ways - apache uses mailing lists almost exclusively - if you have a discussion, your job is to get it written down and posted to the list. Don't just write down decisions you took, but write down why, and decisions you rejected so it's documented. Chandler uses mailing lists for discussion, and a wiki for documentation, and a status manager for posting staff's weekly report. Mozilla has a web site and mailing lists, plus a fanzine, which is an independent operation started by a friend of mozilla, but not run by mozilla.org.
- work style of the core team. having a geographically dipsersed group requires some changes in work style. Need a core set of people who are comfortably working not face-to-face. comfort level with "life in the fishbowl" - the community can see what you're doing. in Netscape->mozilla transition they found some people were not comfortable. On the other hand, it's a low-spin environment, where you can be comfortable admitting mistakes. Ability to have assumptions and decisions questioned by those with different perspectives and perhaps fewer institutional constraints.
These changes can be hard - at OSAF they eliminated all private mailing lists so all communication is public.
- Mechanisms for people to get involved. Seemingly sinmple mechanisms can go a long way towards helping people get involved - e.g. the Chandler weekly irc chat session for an hour when all staff are online; or Mozillabug days" on irc - instruction and hand-holding in testing. Some days find 4 or 5 new people who can participate. Apache incubator program - more formal, intended for companies or formerly closed projects - assigns mentor from apache foundation who works with the project.
- be hones with yourself about what can actually be done. leadership has to really have a belief that the open source model is good for this project. a community can have many different constitutencies. so there might be 10s of core developers, but thousands of people in the testing program. So you need to figure out which constituencies you're really interested in developing. e.g. mysql folks are not all that interested in encouraging folks contributing code to the core database, but all the things around it. OpenOffice is a lot like that too.
- last issue is one of control - two key aspects to open source are the right to use the code, and the right to fork if you feel the project is not going in the right way. how is control delegated and passed around, how is it possible for a person who is involved and doing a great job to get some control or authority or responsibility?
Turns out to be a key issue in hybrid projects, it's emotional and complex and can take a long time.
Decision making styles -
linux kernel - benevolent dictator model.
apache - consensus and voting of members, or of those with commit priveleges. most projects in apache are small-ish (25 people or less).
mozilla - one ultimate technical authority figure, combined with a high degree of delegation. Try not to use the technical authority. each module has an owner who controls check-in of code, etc. Where they had problems were with module owners who were appointed because their managers wanted them to, rather than came to it from their own passion.
chandler - still forming - set of working groups for now.
Managing the dev process through policy - the mozilla example
Open source projects do *not* mean anarchy or lack of control - Mozilla is actually more controlled than many software development projects.
Module owners have almost total control of the tree.
system for evaluating work of a contributor and their code. All code going into tree must be attached to a bug in bugzilla. Once it's attached it has to be reviewed - first by the code module owner for quality and fit. Then another level of review, called "super review" - it's an integration review. There are 20-25 people who have the authority to perform integration review - check for coding style, proper use of practices, etc. Nobody really likes this, but it's there because it's needed - have policy because they can't stand not to have it. So any piece of code going into the tree has been reviewed twice by two different people.
An elaborate system for how the tree itself is maintained. Who has the right to check code in - depends on the engineers in the project deciding that you know enough - not decided by hiring managers. But people who work at companies (like Sun) like it in the end, because when Mozilla says their engineers are good enough to check in code, it's a validation of the quality of their work.
There's a very formal policy on how reports of security bugs get handled. There are some contentious issues about when these bugs get made public - even if they're fixed in the current build, what about integrating with reseller's derived products like IBM, Netscape, etc.
Mozilla tree closes every morning for testing.
If you've checked code in there are rules for you being "on the hook" - have to be available during the testing so the tree can be built.
Tinderbox - a web-based front end that shows the state of the various builds and links to the web-based cvs stuff so you can see what people have cheked in and what's cheanged, etc.
Mozilla has an enormous testing community, that people don't often think about. Mozilla milestones get a couple hundred thousand downloads - they get a set of crash data and specific bug reports. Hard to match even with a good size QA group.
There is a group of thousands of people who use the product and report bugs. Then there's a set of people smaller than that who are interested in managing bugs - figuring out what's wrong (especially trying to figure out layout problems). Much higher number of people interested in these problems than one would think - bug days enlist people interested in these problems to track down data on specific bugs.
For end-user focused products, there are lots of people who want to do things like testing - doesn't work as well for server-focused stuff.
If volunteers don't buy into the technical leadership, they won't stick around.
The Mozilla Foundation is thinking about the general lack of innovation in end-user-focused applications for the Internet. The real focus for Mozilla is what hasn't happened in web technologies - what needs to be there? Plugins are a disaster, how do we deal with structured data, how does data get refreshed without a whole page refresh? a whole set of business apps that can be used within a browser.