While open source has seen tremendous uptake in companies large and small, there are still plenty of problems you can encounter when building on top of an open stack of software. Here are the top five.
Open-source projects often are ahead of the innovation curve and build all sorts of newfangled things into their code. Sometimes, these leads to large leaps forward. Other times, unforeseen problems can set back development projects. Using such experimental software can be frustrating, especially when no one else has yet encountered the errors you’re getting. This problem, combined with the next, can make for an awful experience for enterprise developers.
Some open-source projects are the brainchild of one. While open-source insinuates wide participation, there are many projects out there where a single developer holds tremendous sway over the project.
Linus Torvalds would be the obvious example, but smaller efforts, such as Jenkins and Google’s V8 engine, are largely the result of a smaller team working hard to solve a problem. That means issues that arise can sometimes necessitate the attention of a very small pool of brains. Certainly, Torvalds isn’t in this category, as there are plenty of smart Linux kernel developers out there. But if you run into a problem while using a small open-source project, and the two or three folks who created it are off on vacation, you could be up a creek. Which leads to…
#!
The time between an open-source project becoming relevant and its gaining a corporate backer is shortening every day. But not every project can pay the bills for a service-and-support company. Smaller libraries and frameworks that aren’t widely used could be extremely useful to your project, but if you can’t call a corporate, liable entity 24/7 for help, it’s tough to sell the use of that piece of software to your corporate masters. But this is only the tip of the iceberg…
The Linux kernel has tackled this issue head-on, thanks to Greg Kroah-Hartman’s efforts to solidify kernel releases for longer-term back ports. But many projects aren’t able to put in the time and effort needed to back-port important changes to older releases. After all, this is open source, and you should be able to do that yourselves, right? But as an enterprise developer, do you really want to spend your time back-porting changes?
There’s nothing more irritating than finding an open-source project that solves your problems, only to discover that it hasn’t been updated in five years. Abandoned projects in the open-source community never actually vanish, they just go static. Thus, while searching for solutions, you could easily stumble across software that hasn’t been updated or received any bug fixes since before Obama took office. While the code should still be out there, the whole point of searching for these projects to begin with is to save you time. Are you really saving time if your team is spending its time slapping duct tape on an ailing project?
