Open Source at Sun

		Print
		Email weblog link
		Discuss
		Blog this

Nat Torkington
Sep. 17, 2004 10:28 AM
Permalink

I spent Tuesday afternoon at Sun with Mike Shaver of Mozilla, Brian Behlendorf of Collab.NET, Fred Sanchez of Apple, James Duncan Davidson, Doc Searls, and others. Sun had assembled several hundred engineers, managers, and even marketing people, interested in the open source process. I'd worked with Sun to help organize the open source speakers, so was quite curious about how it would play out.

I had a great time, and enjoyed hearing people with a lot of experience explain what they found important in open source development. It was great to be able to step above a Subversion vs CVS, emacs vs vi, Perl vs Java type of conversation and focus on what really works. I moderated three sessions, and in every session the same basic points came up again and again.

Visibility

When you open source a formerly proprietary product, and want external developers to participate, you must give them more than just the source code. The external folks need to know as much about the code standards, architecture, release plans, open bugs, development priorities, etc. as the internal developers. If you just dump the source over the wall, the chances are you'll get patches back that don't integrate with the rest of what you're doing. When you reject a patch, frame it as "here's how we'd write it, here are the guidelines we follow".

Consistency

Don't treat external developers as second-class citizens. Not only do they need to know the same things as internal developers, they must be judged by the same criteria. So if a patch is rejected from an external developer, the same patch from an internal developer should also have been rejected. No double standards.

This applies just as much tools as to processes. Same bug tracker, same source control system, same everything. If you release a product, release enough that they can build it. Nothing sticks people to your software like a successful build minutes after downloading.

Bug Tracking

When a release is coming, the release manager identifies the bugs that must be fixed before the release can ship. This serves at least two purposes: it helps get the important bugs fixed, and prevents distractions. I remember a release of Perl that dragged on and on past when everyone thought it would be released, and immediately identified with the "prevents distraction" idea. It's so easy to be caught up in quality issues when you're an open source developer--your name and your reputation is what's at stake. But this can sometimes get in the way of actually releasing software.

Leadership v Control

One session title was "Community vs Control" and the panel almost immediately reframed it by saying "you get the effects of control by exerting leadership". Lead the project in such a way that people want to help, want to work with you, won't want to fork.

--Nat

Nat Torkington is conference planner for the Open Source Convention, OSCON Europe, and other O'Reilly conferences. He was project manager for Perl 6, is on the board of The Perl Foundation, and is a frequent speaker on open source topics. He cowrote the bestselling Perl Cookbook.

Return to weblogs.oreilly.com.