Earlier this week, I unsubscribed from the mailing lists of a pair of Open Source projects. About two years ago when I found the projects, they involved fascinating topics in under served niches. One of those niches – the one customer/user-facing – is still there and under served, but that’s not relevant in the current discussion.
In reviewing the activity on the mailing list, I noticed some interesting things:
- First, activity was very high. There was obviously interest and passion in the subject. That’s a good sign.
- Next, there were some smart people involved in the discussions. That’s another good sign.
- Finally, there was a lot of discussion on what should be done, but nothing actually done.
And unfortunately, I think that was the downfall* of the project.
* Normally I wouldn’t write about this but since the domain name registration has long-since lapsed, I’m considering the project completely dead.
When you don’t have code there’s not a clear direction. No one can quite be sure what the architecture is, how things will interact, or how to make anything work at all. This makes the next person a little more hesitant to participate. It’s not because they can’t, it’s because they don’t know where. When you have code out there for people to run, explore, analyze, and report bugs on, you have code that can be extended, fixed, and customized.
Writing that first line of code is hard. It’s not because it could be completely wrong and stupid, it’s almost the complete opposite. What if it’s mostly right? Has that person opened themselves up to months or years of supporting almost-right code? Have they opened themselves up to random emails and sometimes even phone calls demanding support? Few people have the desire and even less have the ability to handle this.
For the record – within web2project – we had the benefit of beginning with a large established codebase. None of us had to be the guy to write the first line.. we just had to clean up what we had.
The obvious solution is to write a specification.. but there’s a problem with that. Once again, someone has to write that first line. It’s a risk to be the first one to put an idea out there. What if they’re wrong? Since developers aren’t known to be the best communicators in the first place, this can be difficult. Add to this the inherent risk of Bike Shedding and it gets even worse. What could be included as an offhand comment or a complete straw-man could be mistaken as a demand for the One True Way.
I’m not against writing specifications – in fact I’ve written a number of specifications for web2project – but they have to start somewhere. Will it be incomplete? Definitely. Will it be wrong? Probably. Will it be a starting point? Yes and that’s the key. Once there are some bounds on what the idea is and isn’t, someone can start writing code. Someone needs to have the courage and ability to put some thoughts to paper and get something out there.
When there are lots of “smart” people involved.. who writes the spec? When you have a group of people and there are no clear roles, it’s bad. No one is sure what they can or can’t do or how a decision is made. In fact, it seems almost worse when many people in the group know and respect one another. It suddenly becomes a situation where no one is willing to step on anyone else’s toes.
While I’m not a fan of the Benevolent Dictator for Life structure, it has some appeal to it. Having one person – or even a small group of people – who can make or settle a decision is powerful. That person can write the first version of a specification or the first version of the code. Or more powerfully, that group can set the direction for the project in other ways. The most obvious way is through a Code of Conduct (Drupal, Ubuntu) but just day to day behavior sets the tone.
Unfortunately, this project had many of the above problems.
All of the people involved are smart and know each other, but someone stepped forward to write some specs. This was a good step but unfortunately, no one offered any criticism. From various off the record discussions, it appears to be a mix of mutual respect and lack of time. And to top it all off.. those who wrote the specs haven’t had the time to write the code. Those who disagree and have criticism don’t want to write code contrary to the spec.
So how do we do it right for the next project?