by Geoff Broadwell
Related link: http://www.pugscode.org/
Every project has a set of goals that guide it through the meandering
path of development. For some projects, these goals are unspoken, seen
only in the primary style of the code, or in the size and shape of its
APIs. When Autrijus Tang
started the Pugs project to create
a Perl 6 compiler, he had an explicit goal: optimize for fun.
Fondly referred to as -Ofun -- a typical compiler writer's joke,
referring to the standard -O flag used to tell a compiler what
its primary optimization goal should be -- optimizing for fun is probably
the most important decision Autrijus made.
Optimizing for fun has had tremendous benefits. In just 8 months, the
Pugs project has gained well over 100 committers, averaging about 30
commits a day for the life of the project. Unlike many projects, these
commits do not all come from a handful of people. In fact, the 3 busiest
developers can only claim about half the commits; the rest are well spread,
with 50% of the developers able to claim 9 or more, 25% having 24 or more,
and 10% having over 150 commits each!
The team is not just productive, it's also creative. Starting
with just a single interpreted backend written in Haskell, Pugs has added
have been written or ported, ranging from encryption algorithms to IRC bots.
Various developers have experimented with concepts ranging from continuations
and coroutines to
preludes and efficient type inferrence, with working code often leading
the official specs.
Of course, this should come as no surprise. As any cognitive science expert
will tell you, fun
is a great way to focus the mind. Developers that aren't enjoying
themselves will slow down, write buggy code, make poor decisions, and
eventually leave the project (even one that pays). Conversely, rampant
fun will bring coders in droves, and give them a passion for their work
that shows in quality, quantity, and goodwill. It's a pretty good bet
that optimizing for fun will produce a better product than almost any
So what's Autrijus's secret for -Ofun? As he puts it, "the essence
of fun boils down to instant gratification and a sense of wonder and
discovery." Or as chromatic calls it, imagineering. It turns out there's
quite a bit that goes into that:
- Make -Ofun your primary goal (there can be only one).
Next time you're forced to come up with a vision or mission
statement, try that one on for size. (If management agrees,
you've chosen a good place to work.) Every other goal chosen
for the project should either flow from that one, or be secondary
- Use modern, decentralized version control. If you're not already
using a version control system, shame on you. If you are still
using an old system such as CVS, RCS, or SourceSafe, you're really
missing out. Modern systems offer atomic changesets (so all
edits relating to a single conceptual change can be captured
together), full versioning of directories and symbolic links
(so that files can be moved, copied, or renamed and still
maintain full history), fast tags and branches, and more. Most
important, modern version control systems offer decentralized,
offline operation. Every developer can keep a local copy of the
repository on their laptop, editing and committing locally
to their heart's content, even when network access is unavailable.
When ready for a merge, the developer can push changes to other
developers or to a central "master" repository. Some systems, such as
darcs and the
git family are decentralized at
their core; the excellent
SVK client layers
decentralization on top of a modern centralized system,
- Embrace anarchy. One of the key realizations of modern Internet
projects (the oft-quoted
Web 2.0) is that on the whole, your users can be
trusted. The key is that the users also need to have the tools
needed to repair any damage the tiny minority may cause. For a
development project, modern version control systems can give you
"anarchy with an audit trail". If something does go wrong
(intentionally or more likely accidentally), it's easy for any
other developer to identify and fix or revert the problem.
Having this safety net allows the project to run full-bore without
time-wasting process getting in the way, and without undue worry
that code quality will suffer.
- Avoid deadlocks. There should be nothing blocking a programmer
from committing his code. Mandatory reviews (or even
acknowledgement) before commit are often used to work around
failures in tools or project structure. For example, before
atomic changesets and quality merge tools, it was extremely
difficult to roll back a single change made at some point in the
past; now it is much easier to do so. And without a proper test
suite, it's hard to tell if a change broke the code in the first
place. Any review process gets in the way of instant gratification
(a key part of fun), and turns reviewers into bottlenecks -- if
they are too busy, the project may slow to a halt until they are
free. Worse yet, a "bus error" (a key person being hit by a bus)
may stall the project for good.
- Cast committer rights far and wide. A central core committer
group is necessarily slower than allowing every developer to commit
as desired. Tthe more committers a project can gain, the faster
the project can go, and the more ideas and group wisdom it can
incorporate. Autrijus scans a number of technical groups
2-3 times a day trying to hand out the committer bit, responding to
people's musings, and generally spreading awareness. It's important
also to make committer sign-up fast and easy. Autrijus hacked a
quick invitation interface into
rt.openfoundry.org so that new committers could be invited en masse and sign up on their
own without having to wait for an admin to fiddle with configs.
This helps to make sure that people don't fall out of their
interest window -- even the most casual contributors who just won't
wait for any manual process. If invitation isn't completely
automated (as for example with a wiki), make sure many people
in different timezones have admin rights to invite a new committer,
and pay attention enough to do so.
- Working code is more fun than mere ideas. Continuously push the
team to sketch out ideas in code, committing quick and dirty
protypes that can be refactored as they grow. Have something to
work with and show off to others from the first week of the
project. Get things out in public, no matter what the state, as
soon as possible. The easiest way to do this is to have publicly
accessible version control. It should be trivial for someone to
download the repository and play with it (and then easy later to
edit and join in the fun). When his friends are afraid to release
"not good enough" code, Autrijus often asks whether he can release
it on their behalf, or says that he'd like to talk about their work,
and can they please put it somewhere linkable? He does this so
often that he's contracted it to a favorite one-word utterance:
- Build a rich, supportive community. There are numerous ways to do
this, but most importantly, lead by example. Mentoring and even
answering basic questions should happen continuously. Support
groups should have quick turnaround (IRC is a good choice) and
an open attitude. Encourage random fun tangents, such as the
Perl community's JAPH, obfu, golf, and pervasive Tolkein poetry.
Get every committer to add themselves to the AUTHORS file (this
is a good choice to be a new developer's first commit, if they are
unfamiliar with your version control system). Turn your project
into a culture, one that you would like to live in.
- Excitement and learning are infectious. It's clear that everyone
working on Pugs is having a blast, and the team is poring over
technical papers, attending conferences, and trading information
with other projects at a massive rate. There's a pervasive sense of
high potential and great possibilities, and that sense decays slowly,
even during inevitable lulls. All of this research and
experimentation inevitably creates a ladder of skill, from wizened
experts to fresh newbies. But that's actually a very good thing;
skill ladders are part of the very
definition of fun. True
passion and community-building rarely develop around a project that
doesn't have such a ladder. The more you know, the more you want
to know -- and that's a heck of a lot of fun, cements the team,
and produces some amazing code.
Many projects have achieved some of these by accident. Few have achieved
all of them, and in such abundance. Autrijus gave us all a wonderful
present when he made his decision to -Ofun -- now it's your turn.
How do you -Ofun?
Study confirms findings about fun
With the study about "Fun and Software Development" I can confirm the findings of the
Study confirms findings about fun
Thanks for the link!
-of fun Asterisk->OpenPBX.org
A bunch of developers have forked Asterisk into OpenPBX.org and are enjoying the anarchy and freedom of fixing bugs and getting code in they could not get committed before. It's very infectious. and the enthusiasm keeps building. http://www.OpenPBX.org
-of fun Asterisk->OpenPBX.org
I think this is going to get relatively common unless the old guard starts opening up commits. A number of projects with tight committer rules have been forked of late -- it seems the benefits of free committership are starting to overwhelm the taboo against forking.