Ten years ago, open source software had marginal penetration in the enterprise marketplace. Solutions could generally not compete on features or stability with the exception of a few software titles servicing the development space. Today, many enterprises are leveraging open source platforms like Linux and JBoss to run mission critical applications much as proprietary software was leveraged in the past, but with a fair amount of cost reduction with the elimination of licensing fees.
But open source is not really about eliminating licensing fees – it’s about changing the way we solve problems and participating in a community to achieve more robust and complete solutions. It’s about sharing a solution with that community and having that solution come back to you in the next application release in a more refined and complete state. It’s about knowing that core capabilities you needed and built as an overlay to applications in your portfolio will continue to work in future releases. It’s about influencing the direction of the software you use in a positive way to reduce the level of risk associated with ongoing maintenance and software upgrades in your application portfolio.
Participation in open source does not have to incur a line item charge on our P&L statements – neither does it require exposing the crown jewels of corporate IP or otherwise give away competitive advantage. It simply requires a better sense of collaboration, an understanding of common capabilities, a certain measure of packaging discipline, and a governance structure to align and manage change accordingly.
Consider the following questions and then ask yourself – should my organization participate or simply consume?
- Does our open source software meet our needs completely? How many features are we waiting for someone else to build?
- Can we reliably rebuild the software we use if the prepackaged applications in our distribution are deprecated and taken offline?
- If we run into an issue within open source software that takes down our production environments or introduces significant reduction in capability, are we completely reliant on external support to resolve the issue?
- Which is more important to our organization – holding a vendor accountable for flaws in the software we use or resolving the issues quickly and completely?
- Do we control when we upgrade key software, or do we let deprecation of support when we upgrade to a newer OS versions drive application upgrade efforts?
Contact us if you would like to learn more about how you can use open source to minimize operational risk and drive solution delivery more effectively than you might otherwise manage with proprietary software solutions!