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.
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.