Corporate open source advice
Some surprising moves, such as the much-maligned mission statement, can help corporate open source projects work, said Ben Collins-Sussman and Brian Fitzpatrick at the Google Speaker Series.
The two Google developers put corporate participation in open source into four levels ranging from fake "open source" all the way up to giving a project the autonomy to make its own major decisions.
Faking it, or "level 0" participation, is doing PR blitz around open source but not actually using an open source license. "There isn't a lot of point to doing this unless you want to destroy trust," Fitzgerald says.
(Two related approaches that didn't come up were the weasel words "to the open source community" which a lot of vendors use in PR about proprietary products that interoperate with open source, and the YAFL approach, of using a license that's License Proliferation Initiative-approved but not compatible with the main licenses in your chosen field.)
Moving on to real open source, level one is to "throw code over the wall." Fitzgerald describes this as, "Clean up the code, get it approved by legal, release it. It's pretty effortless." The drawback is, he says, "you don't have any commuity to keep your software alive, and if it does form it's going to form far away from you." A company choosing this approach will lose control of the future direction of the software. One exception is media codecs, Fitzgerald says.
Level two is "develop internally, post externally" Collins-Sussman likened this to "throw over the wall," but on a daily basis. Discussions happen internally, and outside contributors can only see the actual source code and maybe some commit messages from the revision control system. "If you don't let everybody take turns driving the bus, you're going to get drive by patches," Collins-Sussman says.
Fitzgerald says you'll get "followers" who might do a quick fix, but it's difficult for outsiders to see where the code is going next, so you're unlikely to get major work.
Level three is "open monarchy," which is like level two except that discussion takes place in public. Contributors are still mostly employees, and a project lead inside the company makes decisions.
"You will attract better quality volunteers. They have a better idea of where your roadmap is," Fitzgerald says. But this level of participation is most at risk of what Collins-Sussman calls "angry revolutions," in which a group of outside developers creates a fork.
The final level is "Consensus-based development," which makes almost all project information public, and, as Collins-Sussman puts it, "the people who are members of the project are the ones who make the decisons. People are wearing two hats." Even an employee assigned to work on the project will have to prove himself or herself to the rest of the developers. He described the case of a CollabNet employee assigned to work on Subversion. Instead of just following instructions and checking in code, the employee had to "earn access" from other developers on the project, including non-employees.
Fitzgerald warns, "You're not going to get a big boost from this right away," and points out that employee contributors need political, not just technical skills. "You need to hire strong leaders. You can't just throw people at the problem."
Although bringing outsiders into the project does mean a lot of work, Collins-Sussman says there are three advantages. First, it creates a hiring track for finding outside developers who know the project's goals and code, and have already shown that they can work with the team. "When people get full ownership of the project, they drive the bus. Then the company says we want you to do this full time, instead of just on weekends," he says.
Second, there's an information-gathering role for outside contributors. Steering the project "The closer you can bring the consumers of your code to the people writing your code, the more you can get more productive engineers and better software," Collins-Sussman says. This seems like a waste of time at first, Fitzgerald says. "If they're writing the wrong code it doesn't matter how much code they're writing," Fitzgerald says.
The third advantage is project longevity. "Participants will come and go but the process will last a really long time," Collins-Sussman says. "The Apache web server project has been going on for 12 years and peole have come and gone," he says.
The consensus approach requires seeding the project with code, culture, and staff. "Start out with a small group of humble people who work well with others. It becomes a self-selecting group," Collins-Sussman says.
"The world is full of jerks, except the Internet makes it seem like they all live right next door to you," Fitzgerald says.
Surprisingly, a mission statement is a big help, Fitzgerald says, especially one that sets "non-goals." Put the mission statement on a web page, and point would-be contributors to it if they suggest something outside the project's scope. Fitzgerald recommends the book Producing Open Source Software by Karl Fogel.
Although project culture needs to be respectful and polite to attract productive contributors, many in-house developers will need cultural training to get used to honest code reviews. "In the corporate world, in many companies this is not normal. People own certain areas of code, and if you comment on what they're doing it's taken as a personal offense," Collins-Sussman says. Teach developers that "You are not your code."
Fitzgerald says newly open sourced projects need to make an effort to stop using internal mailing lists. And, Collins-Sussman says, the archives of an external mailing list help attract new contributors. At CollabNet, the CTO made employees take some discussions public, and, Collins-Sussman says, "a few months later some of the best developers showed up." Start with one list per project, and split into developers and users list only when there's too much traffic to handle.
One key problem is interfacing a consensus community to the market demand for a feature. What happens when a sales person comes in and says, "I can close this multi million deal if I can get this feature?"
Fitzgerald says that the company needs to see if a customer feature is one that the community will tolerate. If it's something that's completely out of scope for the project, it won't work. Collins-Sussman gave the example of locking for Subversion, which a CollabNet customer asked for, but no community member was interested in. Because CollabNet could safely add the feature, an employee did it and got it in.
Syndicated 2007-10-26 19:14:41 from dmarti's blog
