Enterprise IT departments should revisit their application development strategies to follow some of the approaches used by Facebook and Twitter, argues RedMonk analyst Stephen O'Grady in a recent blog post. Specifically, he says you should invest application development resources only in applications that differentiate your business from your competitors, and rely on open-sourcing and permissive licensing to extend your reach and your development dollars. I believe he's right.
Unfortuately, most organizations develop too much software that doesn't really differentiate them; they should be using packaged or open source software instead for those needs and refocus their internal development efforts higher up the business value "stack."
[ Keep up on the current open source news and insights with InfoWorld's Technology: Open Source newsletter. ]
But in some cases, such as where there's no appropriate open source or commercial software available, you should consider developing an application in house and then open-sourcing it, using a permissive license into a third-party hosting site or foundation such as Github or Apache. The use of a permissive license, such as the Apache License, and external hosting helps others in your industry find the application. If you're fortunate, they'll contribute to evolving the application. That spreads the development costs over multiple companies.
Well, that's the theory. Putting it into practice is of course an altogether different issue. This new development model requires a major shift in line-of-businesses' and IT decision makers' mind-set. It's one thing to use an open source product, such as Linux or Alfresco, within your enterprise even while knowing your competitor is doing the same. It's entirely different to open-source, for instance, your custom-developed partner-onboarding application and watch your competitor use the application also.
If you can get over that mental barrier, do note that your company actually owns the copyrights to the source code. Some enterprise developers unwittingly use open source code for internal projects without considering the implications of its open source license. They assume, for example, that the application will never be distributed outside of the company, and thus that the license requirements will never be triggered. Many open source licenses have rules about redistribution that you must honor.