The Open Source Tipping Point – Is Your Enterprise Prepared?
Long-term Maintenance of Open Source
At some point every team realizes that an early or quick decision to use an open source package has become a long-term maintenance and update commitment. This is the tipping point for organizations, that moment where a sudden outage, discovered security flaw, or delayed release tests the team and triggers a rapid shift in people and processes when they’re caught unprepared.
Organizations embrace open source software (OSS) for many good reasons but there are equally strong cases where OSS can cause problems. The rapid shift from proprietary vendors to open source communities – Gartner predicted that 99% of the Global 2000 will use OSS by this year – means that organizations not addressing the unique challenges of open source are setting themselves up for big costs down the line.
Back to topAwareness of Three Types of Incidents
Based on over ten years of handling issues with mission-critical enterprise systems, there are three types of incidents that we’ve seen repeatedly.
Open Source Production Failure
First, and by far the most costly, open source in production can go down. Whether it’s at the operating system level, the database, or middleware, a misconfigured or even poorly chosen package can fail, affecting end users and testing the limits of developers’ knowledge and debugging skills. If multiple packages are involved, isolating the fault consumes even more time.
Unlike the open source community, enterprises are at significant disadvantage when package-specific experience isn’t available on the team – end users don’t care that the community is slow to respond, they just want their system back online.
A recent example illustrates the potential fragility of open source, where a very small and widely-used piece of code went missing (for unusual reasons), affecting major websites like Facebook, Netflix, and Airbnb. If a team didn’t have the skills to fix the issue, their users had to wait for the originating source to do it for them. (We reported on this in our OpenUpdate newsletter, which is free to sign up)
Open Source Performance Issues
Second, just like proprietary software, open source deployments can suffer performance issues. Unlike proprietary software, there aren’t many people that have experience with specific, customized enterprise environments. Whether the result of poor package selection, improper database and network tuning, or issues within the packages themselves, it takes a community to scale capacity to meet changing user demands … but the community is rarely available to meet your timelines.
Issues During Development
Third, with open source now at the core of enterprise systems, any issues during development have a greater impact on release cycles and production upgrades. Unless the company has invested the time and training to nurture talent across all open source packages in use, it’s a struggle to find solutions for release-impacting bugs. It often falls to the developer to research, test, and iterate fixes on their own –all while end users are waiting.
Back to topConclusion
With the way open source has taken over, and the risk of potential issues, enterprises have no choice but to adapt. This means going beyond traditional thinking around proprietary sourcing. Ask yourself: If we don’t have the people to support this open source internally, how can I make sure we’re covered?
To learn more about common enterprise packages and the top issues around them, download the complimentary Open Source Support Report.