“So what is passed over the wire? Is it some form of compressed text containing SQL, XML or JSON” – Me
“No. Its our own custom, proprietary binary messaging format.” – ISV and soon to be partner (who makes some enterprise-type software) we have to integrate with
Why is it, that in this day and age, there are still ISVs (some rather small) that think a home-brewed , closed (either in terms of standards or source code), component is better then using or implementing something open and community developed.
Commodity components
If I may be so bold, I would argue that components that have already been developed in the open should be considered as commodity and these ISVs are better off innovating higher up in the application stack. This can take place by either using open source libraries that already implement open protocols or building components based on open standards. Not adopting this approach is akin to the automobile industry not using OEMs but rather manufacturing every part of their car on their own. If BMW and Daimler can move towards co-operating , wouldn’t it be silly for ISVs not to be doing the same.
Resistance
The common arguments I have heard again such moves tend to be:
1. “Our closed components are a competitive advantage. We do not want to adopt something that will make it easy for other players to speak to us.”
Guys, welcome to the 21st century. Interoperability and data portability is becoming important, and more so in the enterprise space. The tides are changing from closed to open systems and customers are being reeducated to see this as a feature. Using standard or open components will give you this feature for free, without extra effort.
2. “But this is our secret sauce, our differentiator”
This is a bit more tricky as there might be situations where this is valid. It seems counter intuitive at first, but the more niche and specific your product is, th more sensible it is to roll your own and keep it inside. However the more general and mass interest it is, the more sensible it is to open and collaborate.
A simple rule to determining if this is a valid argument is to determine if there are existing open components or standards implementing what your secret sauce does. If there is, its time to search for a new recipe as your secret is being commoditised. Instead of fighting, collaborate on this component, benefit from the extra eyes and feedback and move up your value chain.
3. “We have custom/specific needs”
I find it hard to believe that if your component is general enough to have open standards or implementations,your use case is so specific that it is not catered for.
A tangential use case might be indicative of a deeper architectural issue. This would be a be a great time to ask the question , “Why isn’t anybody else doing it this way?” and “How do other folks tackle this problem”
Lastly, maybe the need has not been catered to yet, instead of turning away and rolling your own, use this as an opportunity to engage and discuss these needs with the community. This is your opportunity to contribute ideas and embrace the community instead if running off and cooking your own.
4. We don’t accept open licensing (AKA – Open source, isn’t that like communism ?)
In this interconnected world , no ISV is an island. If Microsoft can open up to the need of dipping its toe in the open source lake, then its high time you do too. Although code contamination is a concern among some quarters, that matter should be handled by more stringent code audits and license criterias when using open source code. Some licences such at the BSD and Apache have been argued to be more business friendly then the GPL. These licences allow for collaboration and closed environments to co-exist. Issues regarding software patents are sometimes raised, however, with software patents, you are effected as long as you write software, closed or open.
Upsides
There are many upsides to sticking with open standards or components as well, such as reducing the need for training of new hires as well as ensuring that the development of the component does not get stale due to lack of upkeep the code. There is also the benefit of continuos review and injections of ideas from the community, things that your homebrewed code or specifications will never benefit from.
Caveot emptor
At the end of the day though, the decision is surely going to need to happen on a case by case basis. There might always be a good enough reason to go it your own. I hope, however, that we raise the bar on these type of decisions and realise that sometimes the decision to go your own is less sound that it initially seems.
At the very least I will be able to spend more time writing and reading blog posts then wrting code to push proprietary binary bits around.