Replaceability

Yesterday I spouted forth some worthless gibberish about "Permanence". Today it's more of the same. New topic: replaceability.

The commercial software industry is built on some classic business theories, such as building a proprietary advantage. Customer lock-in is another. Get your customers to buy your product and you can do what you want, as long as switching to your competitors is too painful.

The "Do It Yourself" (DIY) system remains the leader in the very-crowded content management market. Why is that? After all, nobody writes their own web server, database server, or word processor? I think the dominance of the DIY system and the overabundance of products is partly due to customer unhappiness. And I think this unhappiness can be connected back to lock-in.

In my opinion, open source content management --- OSCOM --- can take advantage of this customer unhappiness by deeply embracing replaceability. Make the fight against customer lock-in a deeply-held value which is translated directly into software features. Tell the customers: "Your business strategy counts more than our software strategy. We'll back up our words by ensuring you can throw out our product and switch to another OSCOM product without losing everything you've invested in."

Replaceability is also future-proofing. What if the vendor goes out of business? What if the open source project is in trouble next year? Customers have the right to not hate themselves in the morning.

Alas, this isn't something open source is good at. As Gregor and I wrote last year, tribalism and disinterest are challenges.

Thus, what is the upside for OSCOM projects that embrace replaceability? First, we can tap into customer resentment. In my opinion, this lock-in issue is a raw nerve. Customers know they are cows being milked to prop up stock prices.

Second, I think it plays well in the media. Gregor and I saw this with the Builder.com article and the Slashdot thread in response to our Advogato article.

Finally, having a moral compass is good for business in the post-Enron world. A business should be have a belief system that extends beyond "increasing shareholder value". Of course this is just a belief, and in board rooms, beliefs aren't as cool as liquidity. If commercial software can't be about beliefs, well, OSCOM can and should.

What is the downside for OSCOM projects? First, there is work involved. Embracing standards isn't as sexy as created a new universe from whole cloth. (See tomorrow's gibberish on this topic.) Developers love puzzles, and implementing a spec is less rewarding intellectually than writing your own template system, schema language, or protocol.

Related to software replaceability, I also believe that leaders should make sure they themselves are replaceable. Good ideas should survive if the founder gets hit by a bus, and it is the responsibility of the leader to ensure this. This means working to grow the next round of leaders, delegating the work, trusting in the participants, and having patience with messiness. It ain't easy, amigo.

Customer lock-in is a drug that hard to kick. Embracing the alternative seems like heresy. "We are going to spend manhours ensuring that people can throw out our system? Are you nuts?" Well, yes, I'm nuts. Because I think that customers are smart, customers are pissed, and by putting customers first, we'll get more customers.

Tomorrow's gibberish: The Inventor Disease.