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?
Technorati Tags: sayings, productmanagement, coldfusion, adobe
*of course* all developers are silo developers. *of course* all technology that requires any kind of user lockin requires developer lockin as well.
Everyone knows only what they know; you can broaden your own 'silo', but you're still siloed. I, for example, still don't grok functional programming in any meaningful way. So I'm stuck in the procedural/object-oriented/mainstream 'silo' there, and as a consequence I don't get Seaside (or the advanced parts of ruby, or what Paul Graham is going on about).
The silos that open-source developers find themselves in might be differently organized, though. The primacy of community in the open-source world can lead to insulation from outside opinion, and (for example) the LKML is a hostile and alien environment to someone who just wants to find out how to get pretty graphics on his Debian box. So rather than being siloed on a technology, they're siloed on an idea or three.
One difficulty is when the cost-benefit tradeoff decision function for a developer is too different than that of an end user (individual or organization). E.g., an end user organization doesn't see the cost of bugs they haven't encountered, and any change that isn't purely fixing the bugs they've reported or adding features they've requested is going to be a negative due to the
instability that may result. A problem in some open source development is that community developers may not be motivated to consider the long-term maintainability of their source in the end user's environment, not just in the development environment. (And vice versa, when end users contribute code back to the trunk and expect that it'll be maintained in the way they use it.)
Open development processes can give the end user visibility into what's going on. One positive outcome of this is if the end user develops empathy for the other end users and can feel that changes are being made for the set of end users as a whole.
End user community management is important in closed processes as well, of course. Large software companies have user group meetings, and some long life products develop active fans (e.g. http://www.openvms.org/).