I have a saying I like to throw around: “the shackles of success.” It’s a nicer way of saying “legacy.” Here is the scenario: you, a software company, creates some fantastic software. Everyone buys it. Now, as you want to evolve the software, the business or deployment model around it (like going from partner mediated packaged sales to SaaS), all those successful customers rebel. They don’t want to change, they want things to stay the same, and you to just fix bugs and add features.
People who write software hate doing “version 4″ of the software. Developers loath working on the same technology over and over again. Any why would they? Developers don’t have a culture of stable, long-term jobs. Instead, they get rewarded by learning new technologies and hoping to new jobs. Whether this model is healthy for developers, companies, and customers is left for another tangent.
Reading over the wikipedia page on ColdeFusion, the idea of “shackles of success” came up. To my “standards bigot” eyes, ColdFusion looks like a proprietary silo, mixed in with all sorts of standard technologies. That is, you have to be a ColdFusion programmer, not the more general Java or C/C++ programmer. (Tangent: maybe there is no general programmer, they’re all silo-coders?). Granted, reading through all the functionality that ColdFusion provides, it looks like several ColdFusion features would have saved me time (though cost however much per a CPU, seat, and/or distribution), for example, doing things like converting HTML pages to PDF (yuh!).
My knee-jerk advice, of course, would be to open up and standardize the ColdFusion platform. It seems they’ve been doing this for sometime, but they’re no doubt limited by the shackles of their success. The ColdFusion community probably likes, or is “OK,” with CFML and friends. Why hoist some new development paradigm on them? Indeed, market-wise, it’s risky for any successful platform to introduce a “new way.” Organizations then think: “if I’m going to go through the trouble to learn this new way, why not shop around for entirely new platforms?”
This got me to wondering if more purely open source projects have the same problem. Of course they do, but the way a project/community can react to the shackles is probably different. There’s always forking, but more sanely, there’s starting up sub-projects. The important pivot on (at least, more purely) open source projects is that product management is as closely bound by revenue maintenance and generation. The idea of “the shackles of success” is largely one about protecting and continuing existing revenue, though partly one about keeping your community happy. Ideally, those two concerns intersect, but in practice, there’s plenty of room in the disjoint parts of those sets to fool around in. Making money, of course, usually wins over keeping the community happy, esp. if you’re a public company.
Now, I am in no way saying anything about ColdFusion itself: it’s just a launching point for the chain of ideas above. Instead, I’m wondering how product management in open source projects differs because the concern for revenue generation is not as big of a “stake-holder.” That’s sort of a naive view: of course money comes into play, esp. the money the developers and community members make off the platform! But, there is something different, and it makes me wonder: do the shackles of success apply the same for closed and open source code?
I feel like this thought train will lead me back to a some clutch of lessons I’ve already learned long ago, but, what the hell, why not a little Monday morning thinking out loud?
Previous Topic
