CIO JP Rangaswami at investment bank Dresder Kleinwort Wasserstein talks about why he considers open source a corporate IT asset. In this talk, Rangaswami describes how DrKW wanted to create an internal incubator environment in order to combat skill attrition in the late 90s. In the course of doing this, they acquired OpenAdaptor and discovered almost accidentally benefits of the open source development model.
The talk is a bit fleeting and unstructured (and someone’s phone keeps ringing during the presentation!), but Rangaswami presents a lot of very interesting opinions:
- He observes that the business environment in banking industry (and other industries?) are less focused on standards than before. He believes Open Source development has a better chance of achieving cooperation than standards in a business environment where “everyone want to be top dog”
- He explores the model of Open Source Bonds. A company issues a bond promising to pay whoever develops X (for example) a sixth of what it would cost them to built it in house. He hints to a possible network of brokers and service providers.
Personally, I found the Q&A part the most valuable:
- Question: “What should I tell the executives in my company who consider open source ‘high risk’?” Rangaswami talks about how there are only four interesting risks during software procurement: 1) The vendor disappears, 2) The vendor gets a different focus from you, 3) quality, and 4) security. Open source has a “build-in escrow” clause (just without the lawyers), which takes care of the first two as well as commercial software can. He further points out that within the industry, nobody is held accountable for software failure. This means that quality is not something you can buy. Finally, the inspection value when it comes to security is considerable.
- Question: “What should the architecture department be doing?” This was the most interesting question to me. Rangaswami gives a long and thoughtful answer. The architect is not unique and different from everyone else, except that (s)he is more committed to learning. The architect should work through “control-freakery”, but through influence, advice and support. An architect should not “try to write an architecture (I am proud of being accused of not having one)”
- Question: “What is the main cause of project failure in the software industry?” Rangaswami points out how we’re not very good at saying “no” to the customers. Project failure is caused by a culture that is unwilling to accept failure. What is “worse than failure”? Not learning from that failure because you’re not accepting it.