I recently came across this article, advocating the use of open source within organisations:
There are many reasons why going open-source is good for organisations, and almost as many reasons why its not likely to happen any time soon. However, an interim ‘enterprise open source’ approach may be useful – enterprise software written using open-source governance and change control principles, but where the open-ness is restricted to enterprise use.
Why would enterprises want to do this?
Simply put, technology reuse across enterprises is going to be very, very difficult (if not impossible) to develop in an economically viable way without it. And there are many other benefits, such as giving developers stewardship of business software, encouraging developers to build software that they know will have other eyes reviewing it, improving build/compile automation processes, improving deployment processes, reducing key man dependencies, reducing vendor lock-in, reducing the need for formal code reviews, providing a longer-term ROI for investment in software, etc.
So while not everything in an Enterprise Open Source effort could (or should) be reused, the mere act of building software in this way will improve how software development is perceived and treated in firms that are technology enabled, but are not technology vendors.
Many developers are reluctant to build software that can be exposed to others for critique – this is natural when developers are forced in many circumstances to cut corners to meet project deliverables, even at the expense of technical debt. It’s time to put the technical debt in the spotlight: maybe you don’t have the time to fix it, because it doesn’t need to be fixed for your project. But someone else may think its worth fixing for their project, vs the cost of developing something entirely new.
From an audit and control perspective, I suspect that in well written code, there should be very little sensitive information in code that cannot be shared at the enterprise level: most likely, any such sensitive information should be captured in its own repository, with appropriate controls to restrict access – i.e., a separation of concerns, architecturally.
I believe a top-down sponsored approach to enterprise open source is necessary to allow the development of truly reusable services (encapsulating data and function in one or more modules), modules (encapsulating function only across multiple packages) and packages (encapsulating functional building blocks for modules in the form of JARs etc).
Without it, effective technology reuse will rely only on top-down governance – a level of control and oversight that is expensive to provide and is mostly ineffective, especially for larger organisations. Rather, developers need to be recognised for the code they steward, and the code they reuse/contribute to, and this combined with a top-down reuse strategy should yield the best outcome.
Would any CTO stick their neck out and advocate this approach?
Note – the above is separate from the issue of whether firms that use open source should contribute back to the community. In particular Amazon has drawn some attention regarding its official policy relating to employees contributions to the open source community. This may be the subject of a future blog post..