There’s a great paper out of Harvard Business School, written by Carliss Baldwin and Kim Clark, entitled The Architecture of Participation: Does Code Architecture Mitigate Free Riding in the Open Source Development Model?
A mouthful of a title, to be sure. But it offers key guiding principles for the architecture of new open source projects. Namely: provide modularity and option value in a small, highly functional core, and the community will have a much higher incentive to add value via new modules. A great game theory-based proof of “why open source works” — when it’s done correctly, of course. A must-read for anyone starting any open source project, IMHO.
These are the principles that have guided the first two weeks of the Func project. Func stands for “Fedora unified network controller”. It could have been called Yet Another Systems-management Tool, but hey, that acronym was already taken. The goal of Func: provide a *dead simple* “management” agent that authenticates trivially and securely to a central server, listens and talks over xmlrpc/ssl, logs *everything* for future auditing, and has useful and well-documented modules that provide simple/powerful examples for writing other useful and well-documented modules. It seems to be the tool that every sysadmin has always thought about writing, but never quite got around to.
Maybe it will be awesomely successful. Maybe it’ll crash and burn. But that’s what’s so great about Fedora: we have the freedom to try it out and see where it goes.
The takeaway: it’s not enough to write code and say “look, it’s open source.” If you want to build communities around useful open source projects, you must architect them the right way to begin with. (c.f. Apache, Firefox, Drupal, et al.)