Radiant users and developers,
Over the weekend I took the time to watch the presentation by Evan
Phoenix about Rubinius that was given at MountainWest RubyConf 2008,
available from confreaks.com (You should watch it, too!). I was mostly
interested in hearing where Rubinius was technically, but his talk took
a very different path in that it focused on how community is being
fostered in the project. His primary points were about encouraging
experimentation and lowering the bar of entry. Some of his comments
really struck home with me, which I’ll paraphrase here:
- A team of ‘core committers’ tends to stifle debate and
experimentation and marginalizes those who have differing opinions.
This also has the effect of slowing progress on the project when the
core team is unable to participate. If someone is enthusiastic about
contributing, that should be fostered, not squelched by a high barrier
to entry. - If a project is open-source, it should be much more open than most
projects actually are. Rubinius gives ‘commit bits’ after the first
accepted patch. This promotes the feeling of a real community project,
rather than a closed, orchestrated one. - Small changes often encompass some of the greatest effort. One
should allow small, incremental changes, no matter how tiny. - It’s ok to make mistakes. No one, even a ‘core committer’, is
infallible. Learn from your mistakes, document them, and move on.
The pace of Radiant over the last few months has been slower than
snails. I want to remedy this. I also want to
make amends for the ways that I might have squelched dissent or
artificially slowed the progress of the project through over-engineering
the timeline and smashing potentially transformative ideas.
To this end, I want to attempt an experiment. The first step is that I
would like to open up the codebase for more experimentation. I have
created a clone of the Radiant Subversion repository on GitHub
(http://github.com/seancribbs/radiant/tree/master). I encourage
everyone who is interested in hacking the Radiant codebase to fork it,
make your changes, and send me pull requests. During this experiment,
we will also be maintaining the traditional SVN repo and I will push
changes to it when necessary. For those who are familiar with ‘git’,
this should be an opportunity to try out that cool feature you’ve always
been wanting to build. That said, I’d like our basic ground-rule to
apply, namely, that any patch you submit should have adequate specs.
Although we like to pride ourselves on our specs, the coverage in
Radiant is still not exhaustive, so any patches that improve the quality
and quantity of specs are also greatly encouraged.
The second step is that I am going to start restructuring my time to
give Radiant the TLC that it needs. I want to be a more nurturant
parent. Earlier this year, John L. asked me to take responsibility of
the programming aspects of the project so that he could focus on the
design. In recent weeks I have found that I am not logging a full
40-hour week on my projects, and yet Radiant is not moving forward.
Therefore, I will block out one day a week (Friday) to spend tending to
Radiant. During this day each week, I will be developing the codebase,
addressing tickets and patches, and possibly working on a podcast. I
also intend to have “office hours” on the #radiantcms IRC channel on
FreeNode all day (8AM US Central to about 6PM).
My hope is that both of these steps will give Radiant the shot in the
arm that it needs. I’d appreciate your thoughts and feedback.
All the best,
Sean C.
P.S. Incidentally, a solution to Josh F.'s problem with building a
project with the Radiant source in the root could be solved with
git-svn, allowing him to keep up to date with the source of Radiant
while building his own project in the same tree. Git is much more
powerful at managing multiple sources of changes.
