On Friday 01 Jan 2010 7:16:24 pm Krishnakant wrote:
For example, GNUKhata, the project I initiated and Brought this far is now stable and ready for use, this happened due to the generous funding from NIXI and support of Comet. But now we will soon die out of funds and might not be able to sustain development at the current pase. Voluntary time given by a bunch of hackers can't make commertial quality software. So if we need high performance accurate and commertial grade free software, dedicated team has to work full-time and such a team can only work with some financial security.
I totally disagree - I can point out to thousands of commercially viable highgrade projects that are run totally by volunteer hackers in their spare time. I can also point to huge piles of crap - software designed by a committee and supported with funds. The day the funds die, the software dies. Guido Van Rossum once said: if you cannot sell it commercially, you cannot sell it as open source. This goes to the crux of the problem. As far as I know all successful open source projects follow the principle of - sell it. free it. A classic example is django. It was designed by a team in an online newspaper which used it for a few years (and are still using it). Then they decided to open source it. Since it was already a proven commercial success, the web development community lapped it up - it now has thousands of users, and, more important, hundreds of contributors - all voluntary unpaid part timers. Even the core devels are all voluntary unpaid part timers - although most of them use django full time in their jobs. Or another package - koha, an even bigger success than django. Same thing - they sold it. Then they freed it. And they huge number of voluntary contributors. Note that I am talking about application software and not system software like the linux kernel. Anyway that is in general. I would also like to share my own experiences.
I started off by releasing AVSAP - I had developed this for a customer who used it for several years with no problem - but I did not really sell it. One customer does not really count - and anyway I had no time to push it. I more or less released it for kicks, but it did not take off. Nor did several other projects of mine which I thought would have a huge impact. But funnily enough 2 projects that I started with no thought of developing them into packages for general public - actually took off! Huge number of users (which by Indian standards means more than 3) and huge number of contributors (again that means more than 3). One of them, fossconf, has been used in 3 Indian conferences so far, and will possibly be used by more. It has attracted contributions from over 10 people, although there are only two core developers. However it was tested in practice - so 'sell it, free it' applies (although it was never sold in a commercial sense). The other - openstreetmap.org.in - was never intended to be a project at all. I was just trying to get some of my own symbols into openstreetmap so that I could show off to my friends in the golf club. That has also attracted a fair number of users - and several active contributors.
Neither of these projects are rocket science. No great path breaking code there - so I am unlikely to be ever invited to keynote in fsck.in for example. But I have learnt a few lessons that I would like to share:
1. However hard you work, however great your code, however much finance you get - your application must fulfill two criteria. 1 - it must work and do what it is supposed to do. 2 - it must fulfill a need - ie be useful to some one. Just because it is free software is not good enough.
2. all good successful applications are run by people with domain knowledge - a bunch of IT professionals can never put together a successful application. I have been watching the FA scene in India - and can confidently predict that we will never develop an FA package until some enlightened CA gets involved. If I had developed a package for lawyers, I am sure it would be a very fast moving item.
3. all good successful applications must be multiplatform - yes, that means doze and mac. If they do not run on them, most of your potential users vanish.
4. most important of all - development must be done openly. Any software where people labour for months in secret and then suddenly 'release' their software is bound to fail. You need testers at every stage - not after the software is 'complete'. It is hard work to cater to the public. Complaints and queries must be encouraged, the mechanism for them set in place and response must be prompt. Even if your co developer is sitting in the next chair - document all your communication with him through mailing list, bug tracker or wiki.
5. do not wait for people to join up and help. Go ahead and develop. Many people make big promises - but do not fulfill them. If they *do* contribute - cool. If not, no big deal. Do not run after them and beg/nag.
6. if your app clicks, money and support will come.
I personally dump all the code I write into a public repo - sometimes to my surprise, someone comes forward to contribute a bit or file a bug. Nice feeling.
if any one is interested - all I have done is in http://bitbucket.org/lawgon/ - there is a lot of stuff that I have yet to put up. But will when I get the time.