I’ve long been a believer in open source for the enterprise (indeed, my first book was called Succeeding with Open Source and was targeted at an enterprise audience). When I first encountered open source and grasped its characteristics, I was struck by an epiphany: once this was available, who was going to stick with the old way of doing things?
And enterprises gradually made the shift that I expected – swapping out Sun Unix for some flavor of Linux, building new applications on MySQL rather than Oracle, and adopting one of the burgeoning number of dynamic languages like PHP or Python.
For the first few years, open source adoption followed a predictable path: replacement of legacy vendors in well-established product categories due to price advantage. Many organizations also adopted open source because its distribution method (immediate download rather than after a lengthy sales process) made for greater application agility.
Today, however, the creation and use of open source has undergone an enormous transformation. Simply stated, software innovation has decisively shifted to open source. It’s difficult to think of a single software segment that has a proprietary packaged software vendor defining and leading the field.
[Related: The real reason Microsoft open sourced .NET]
This innovation shift changes the game for enterprise IT with enormous benefits – but also a few challenges. It’s important to step back from discussions of specific segments or particular open source projects and understand the implications of this shift – this migration of innovation from proprietary providers to open source communities.
3 key outcomes of open source in the enterprise
Regarding the benefits of enterprise open source use, there are three primary outcomes that open source makes possible:
First, open source levels the playing field. In the past, larger and better-funded enterprise IT groups carried a significant advantage versus smaller enterprises, due to larger budgets and better relationships with innovation-providing vendors. Obviously, in an era of large proprietary license costs, having more money provides a clear advantage. Less obvious is how large spend provides access to vendors and offers the opportunity to influence product direction and functionality. The net of this was that small users suffered vis-a-vis larger enterprise customers. Today, there small and large IT organizations are evenly matched regarding access to innovation. Indeed, in some cases, smaller organizations have the advantage due to their ability to move more quickly, unburdened by intra-organizational coordination issues.
Second, open source use makes it possible for every enterprise to gain quick access to innovation. When innovation was delivered via a proprietary licensed product, companies needed to fund a purchase to get access to that innovation. Depending upon the vagaries of the budget cycle, IT priorities, and (as noted above) size of spend, actually gaining access to innovation could take two or three years. With open source, that timeframe has collapsed and IT organizations of any size have immediate access to leading-edge developments in software.
Finally, and vastly underappreciated, is how open source allows IT organizations to redirect their budget from undifferentiated infrastructure technology to new initiatives. It’s no secret that IT groups are under enormous pressure from their CEOs to deliver new business offerings faster. That’s hard when most of your software budget is tied up in ongoing license fees. Leveraging open source can take money out of existing systems and direct it toward applications that have more business impact.
One can expect to see tremendous churn in so-called legacy applications as CIOs, desperate to find budget to fund digital systems of engagement, strip out existing applications. Of course, this will cause pain for large proprietary vendors, but it carries implications for the IT organizations themselves. Gartner’s bi-modal IT, which I wrote about here, is a personnel approach designed to ring fence legacy spend and allow investment in more modern applications.
In summary, open source has dramatically transformed the software landscape and offers enormous opportunity to enterprise IT organizations.
But (and you knew there had to be a but, didn’t you?), open source also poses significant challenges to those same IT organizations and – if those organizations don’t address them successfully – may derail the tangible benefits open source offers.
The first challenge open source presents is, well, open source itself. The very innovation I described earlier has led to an unimaginably vast explosion of open source projects. In this very interesting piece, Nadia Eghbal notes that GitHub (the de facto distribution repository for modern open source projects) carries 29 million projects; not all of them are open source (more on that below), but a huge proportion of them are. And GitHub is growing like Kudzu – adding millions more projects every year.
Consequently, it’s a huge task to identify the right projects to use; sometimes it seems that there isn’t one good open source project to use for a particular task, there’s a hundred ok-ish projects. And integration among complementary projects ranges from pretty good to, “well, here’s an example, have at it – and please contribute your code when you’re done.”
Enterprise architecture groups, which for years had a primary responsibility of identifying which proprietary vendor their company should shackle itself to, are now faced with a much more difficult task: select the right open source software components, figure out how to integrate them, and ensure they work together, all in the service of delivering a reliable infrastructure to
application groups. And, with the ongoing work to strip out legacy solutions, this task is only going to grow in scale and importance.
[Related: How tech giants spread open source programming love]
The second challenge is, more or less, an extension of the first. Open source projects are now at the core of IT, so how do you assess the maturity of individual projects? An initial barrier is that many GitHub projects aren’t even really open source projects; as Eghbal points out, many developers just throw code up with no license. That poses a problem for both commercial use of this code (think embedded use within consumer electronic devices), but even for enterprise use, since many companies want to be conservative regarding what they run in their IT infrastructure.
The next barrier is support. Given the provenance of many GitHub projects, support may be totally missing or limited to “post a message and I’ll take a look, if I have time.” That leaves more of the support burden on the software user, and most organizations are reluctant to take that on, especially for components that are not critical to application functionality.
I expect this issue will become higher profile over the next few years, as many IT organizations confront the fact that a developer-made decision about using a particular open source component becomes a long-term commitment to operating and maintaining it. One might regard this phenomenon as “shadow development,” in that decisions made to solve an immediate problem for a developer become ongoing IT headaches.
The final challenge open source presents relates to staff skills. Simply put, open source requires a higher level of technical talent than traditional proprietary solutions, because there’s a world of difference between building a solution and operating someone else’s solution. The latter is the world of certifications and cookie-cutter solutions; the former requires creativity, self-reliance, and technical chops. Newly-hired technical employees tend to come with open source experience and an inclination toward self-generated solutions, while many long-term IT employees are much more comfortable with a vendor-centric world. However, most organizations can’t (and shouldn’t) do a wholesale replacement of personnel. So IT organizations face the task of reskilling existing employees, integrating new staff, all while architecting new systems and ripping out old ones.
It might seem that these challenges are overwhelming, that they are so daunting that most IT organizations will shrink from attempting to move to an open source-focused environment.
Unfortunately, they don’t have a choice. The vendors they’ve traditionally looked to for innovation are, with one or two exceptions, retreated to a “milk the installed base” strategy and have thrown in the towel on innovation. For IT organizations to fulfill their role as the factory of the future, they need to embrace open source, with all its benefits and drawbacks.