Producing Open Source Software by Karl Fogel is the bible for anyone hoping to lead an open source project. When I originally started up Satchmo, I tried to follow many of his ideas. Now that Satchmo has grown, I decided to go back and look some more at this book. While writing up this post, I stumbled back upon The Cathedral and the Bazaar by ESR and noticed some other interesting things that I will comment on in a future post.
In the beginning
Like most things in life, an Open Source project has lots of different phases. In the beginning, I wanted to be sure to leverage the knowledge from all those that have successfully run and Open Source project. I wanted to make sure Satchmo had a good foundation for growth because I knew that projects can start to take on a life of their own. Some of the early critical decisions can come back to bite you if you're not careful! Fogel's book has a bunch of suggestions for starting a project that I took to heart:
First look around
This is a good point. The Open Source landscape is littered with plenty of half-baked projects. I wanted to verify that there wasn't a niche out there that was already being served. In my opinion, there has definitely been a need for a python based shopping cart/ecommerce framework. In fact, the primary reason people stick with Satchmo is the flexibility and robustness of python and django. After a year of working, I have not found another alternative that better meets my needs.
Choose a good name
I think the name has stood the test of time. It's catchy and consistent with Django's naming philosophy. Since it is a nickname, it should translate reasonably well and there's no confusion with other projects named Satchmo. We did recently have some confusion because there is a Satchmo algorithm in Computer Science but it's definitely not easily confused with our Satchmo.
Clear mission statement
Once again, what we have is pretty good. It could probably be improved but it has held up pretty well.
"Satchmo's mission is to use Django to create an open source framework for creating unique and robust online stores."
State it is free
Yup, got that. I think more people understand Open Source so this isn't as big a deal as it may have been in the past. Still it's probably a good practice.
Features and Requirement List
We have both but the features feel a little wordy to me. There's probably some opportunity to tighten it up and make it more effective.
Development status
I think we've been mushy on that. We call it alpha but is that really accurate? I don't know. Hopefully the push to get 0.5 out the door will help.
Version control and bug tracker
Using Trac has been great. I don't know how people managed to run open source projects before the invention of such great tools. I highly encourage folks to use Trac or something similar. The integration is just fabulous. After re-reading the article, I found this quote to be interesting:
"The importance of a bug tracking system lies not only in its usefulness to developers, but in what it signifies for project observers. For many people, an accessible bug database is one of the strongest signs that a project should be taken seriously. Furthermore, the higher the number of bugs in the database, the better the project looks. "
With 117 identified bugs/enhancements, I guess we are doing pretty well. I do think the timeline information does help people understand how active a project is. In my mind, spending the time to get Trac setup and integrated with the web site was a very good use of my time.
Communication channels
Google groups has been the primary channel and with the recent addition of the developer's group, we're doing pretty well. I've been toying around with trying to do some code sprints over IRC but I'm not sure if that would work or not. I will admit that some days the traffic volume starts to get a little high. It's not burdensome but I can see how it would get there.
Developer guidelines
There's definitely some room for improvement here. We have had some informal discussions but there is more we could do.
Documentation
Surprise! There's probably a few areas for improvement here. I am happy with the use of reStructured text and Trac. It makes it easy to present documentation online as well as download and read in an easy format. IMHO, the biggest improvement in the docs would be some more detailed tutorials for common usage.
Example output and screenshots
The demo store should meet this requirement. I am not sure that screen shots really help out. The demo store is also useful because it is a nice check on the development process. I've found issues when deploying the store. Also, having the existing store should help show people that the application actually works.
Where do we stand?
Going back and taking a look at this book and reflecting on the Satchmo development process have shown me that following Fogel's advice really is important. Most of what he says is really useful and if you are even thinking about starting an Open Source project, read his book and try to take as many of his recommendations as possible. I feel like Satchmo has done a pretty good job so far. If I had to rate the project on the above criteria, I'd give us a solid B. What do you think?