Wednesday, October 05, 2005

Pysystray progress - Lessons learned so far

pysystray-0.6.0 and pysystray-0.6.1 (a bugfix release) are out in the wild now :)
 
The major work in the 0.6.X branch is to make the menu's modifiable on the fly.
 
Now, this is what brings me to the crux of this post. On my own, there are some plans I had for pysystray, these plans are no where near what it is now. My point is that my own scope when compared to what pysystray can currently do in its relatively short lifetime, was terribly myopic. Its amazing what real life situations can do to a software project, even a very small one like pysystray.
 
This brings me to another thought. Imagine that I was a company, producing pysystray. Ofcourse, one can say that my users will also eventually create the ecosystem akin to the one i've described. I agree. But the question is, what chances would a single guy like me, have of convincing the next Joe Schmoe to actually Buy n License pysystray? Well, I really don't know the true answer to that, but i have a feeling that it has been easier to build an ecosystem b/cos of the BSD license.
 
That said, I think the most important difference is this. Under a Buy n License arrangement, (aka. Get em, lock em in ;) ), it would seem that once I have my customers, locked in and dependent on me, I am likely to drive the code in any direction that I see very fit, regardless of wether this is neccessary or not. I could decide to begin to add features, and even begin to dream up integration into other products of mine that i'm dreaming up. I can then use that product as a leverage to move other products of mine into the unsuspecting consumers hands. This seem like a wise Marketing move to me. Eventually what could happen, is that small simple pysystray, could be Pysystray Professional 2005 :-), and i'll have standard versions, enterprise editions that can connect to Oracle and even SAP!!! :-) (i can't even say that with a straight face!!! LMAO!!! )
 
Anyway, you get the picture. Let me paint the second picture. In the second case, the code is opensource, so my selfish interests can be uneccessarily served, because once i begin to move in a direction that is undesirable, someone else can very rightly grab the source and fork the project, and i'll be left with a product with no users :). Instead of being selfish, I have to learn to listen to the community that is growing around the project. Some of the users are using it for some very serious projects, and will have really demanding requests to make. Its in the interest of the project, to try to satisfy these real needs as much as possible. That way, the small project gets better and more usefull, and everyone goes home happy :)
 
Let me say here, that the first scenario doesn't neccessarily always happen, but it can happen (and has happened too many times than is good). I belive software should be as small and simple as possible (and no smaller/simpler), serve one purpose (and better serve it well),  and be reusable in ways not originally imagined by the creator. If software does this, it will proove over time to have survival insticts of a virus, as it will keep finding itself used by larger projects.
 
Software written in this way, is easier managed too, and is simpler to finish too. I'm beginning to find that some of my biggest beef with some software, is my total inability to bend them to my vastly superior will (yeah right!!). But seriously, I'm not dumb, and I want to be able to do things the arthur didn't even think possible. This is my idea of Genetic Mutation / Natural Selection as applied to software. If your software can't easily mutate to serve new needs (b/cos there will always be new needs), it is doomed before it is even released.
 
In conclusion, I've been learning that there is truly "Nothing New Under The Sun", as most ideas we think are new, are slight variations of already known ideas. If you combine this with "Scratch Your Itch", then you can really have a successfull project. If you build something just for the sake of building it, its almost likely to fail, or become stuck in a rut later in life. If you build something you actually use yourself, chances are you'll lovingly take care of it, and strange as it may sound. Successful opensource software have a loving arthur, who painstakinly guards against dirty code, wrong ideas, etc, but most importantly, keeps the code lean and mean and relevant.
 
Phew!!! That was a mouthfull...
 
Essien... out.

0 Comments:

Post a Comment

<< Home