The death of an open source project starts when the lead developers stop actually using the project. If it is only being maintained out of a feeling of obligation for those who have downloaded and installed the code, than it’s bound to have a short shelf life. In July of 2006 Stephen Eskin (a former student of mine) and I launched the first version of Project Alumni. We had implemented an alumni application for our High School and we figured we might as well make it available to the world. In nearly two years the project has been downloaded approximately 3400 times. I’m pretty happy with those numbers. Just query google for “Powered by Project-Alumni” and you can get a good idea of the number of sites using the project.

Personally

On a personal level I’ve always been happy with the responses we’ve gotten from the people using the project. For what it’s worth, I’m proud of the fact that this was the first real application I ever took part in developing. I’ve always been really impressed by what Eskin was able to accomplish with almost no PHP experience, and very little development experience. The project really has it’s origins in the need for a teacher to find something for a very bright student to do. We launched the first Project Alumni 1 month after conceiving the project in October of 2005, and most of that credit goes to Eskin.

Professionally

On a professional level I’ve never felt quite right about the codebase. Considering the inexperience of Eskin and I when the project was first open sourced, and considering how much I didn’t know about basic security best practices, I think it’s ok. Ok won’t cut it though when new security vulnerabilities are discovered and I’m not around to patch them. Even though the data we’re housing might not be that sensitive (others might argue otherwise), a member might be using the same username/password that they use for their banking account. If that data isnt’ safe we have a problem. At least we are using mysql_real_escape_string and hashing the password. Actually, the more I dig into the code (again, which I have been disconnected from for a while now) the more I see things that I like. For instance, checking for ‘magic_quotes_gpc‘ and stripping slashes before running mysql_real_escape_string. Good one whoever implemented that way back in 2006. Someone was paying attention to the PHP manual. Probably Eskin.

Support

I basically stopped supporting the project 4 months ago. The only reason I made a commit was because someone started asking me about security vulnerability reports that had started showing up. So, I pushed out a patch and moved on. I used to maintain a website and a help forum, but I decided one day that I didn’t want that burden anymore, especially with a codebase that I wasn’t really invested in. Don’t get me wrong. I used to be invested in the project. I spent 8 hours on my day off once getting the application to install properly and behave on a Windows server running IIS, just because the guy who needed help was a nice guy.

Not Using your own Code

So, how do you kill an open source project? I have stopped releases. I have stopped supporting the project. I have stopped submitting patches. I took down the website and forums. Still, this thing is getting downloaded 100 - 200 times a month. I feel like I can’t just pull the plug. I think the real way you kill an open source project is by not actually using it. I think the best projects are the ones where the lead developers are heavily invested in the security/structure/scalabilty/maintainability of their own code. It was easy to use this project when I was teaching and I was responsible for the websites at Quince Orchard. A security fix was good because it directly impacted a site that I was responsible for. That’s obviously changed now. An up-and-coming open-source software project of mine on the other hand will see a lot of use in the future. A small percentage of our client base at BlueAtlas is a perfect fit for what SimpleMC has to offer. Another percentage of our client base is a good fit after some client specific customization of the application. Some of which makes it back into the project, and some of which does not.

So, to kill or not to kill, that of course is the question. I’m definitely leaning towards no now that I have written this post. I was way in the direction of yes 30 seconds before I started writing. I would be interested to hear what others think.