There has been some chat lately on the sf-uk-mais list by a new round of people interested in putting together an open source student information system (as we call them in the US). I'm reminded of the brutal way time rolls up on this kind of project.
Let's say that it takes one person six months to write and deploy a simple SIS for their school. That's optimistic, but doable, and if they are on-site, they can correct bugs as they go for the first couple years. Anyhow, if you started that project today, you'd be ready to deploy in October 2008.
Now, if you want this to be an open source product that other people can install and deploy themselves, you've got what Frederick Brooks calls a programming product. If you haven't taken this step before, you might guess that it would add 20-30% to your development time. Say, you'd have this part done by the end of the year. No. Brooks rule of thumb is 3x development for a programming product over an internal program, and my experience has borne that out. So then you're looking at having your 1.0 (or 1.0 beta) ready by October 2009. Which is good timing, because that's when people start looking for SIS's for next year. So if you start now, you can have something deployed in schools for August 2010.
This is, of course, assuming that you've just got a very small team and not much money. Also, the 2010 date is for schools you aren't actively (i.e., paid) supporting. You can do it quicker with lots of hand-holding. But getting it to the point where people can download, install and configure an SIS themselves, will take a loooong time, both in developer time and just general product maturity.
2 comments:
Nice post. I think of lot of people who move over to FOSS and especially Linux are assuming that there already should be an open source app for such-and-such purpose.
Your post helps explain why the repositories tend to have an abundance of particular types of applications and a virtual void of other types, especially SIS.
This also assumes that, for an SIS, there is *one* solution -- in addition to developing a tool that addresses a subset of needs, you need to add in the ability to make your specific solution generalized enough where people can use it across contexts with minimal fuss.
Meeting the needs of one school is an easier proposition than generalizing that solution out to meet the needs of a larger subset of schools -- and that's where the real trick is.
On top, of course, of making it so the app is easy to download, install, configure, and use.
I'd say 6 mos to build, 1 year to generalize, and another year to re-design and incorporate changes based on informed feedback. Even if you have a team of 500, it's less about generating lines of code, and more about generating the *right* lines of code.
Post a Comment