The open source software movement has sparked an incredibly rich community of collaborative software developers producing wave after wave of applications. What started as a lofty ideal has become the norm. As many as 93 percent of organizations use open source software and 78 percent run part or all of their operations on it, according to The Tenth Annual Future of Open Source Survey.
Most open source software projects come to life because someone is trying to scratch an itch. A group of coders, or a team of academics, or a fast-moving startup will build some software that solves a very real computing problem, and then they’ll open source the code, sharing it with the world at large. Maybe the coders are trying to help the larger world of software developers, believing that others will find the code useful too. Maybe they’re trying to get more eyes on their code, hoping that others will contribute bug reports and fixes to the project. Or maybe, as is typically the case, they’re trying to do both.
The popular data-crunching tool Hadoop is a great example. Doug Cutting and Mike Cafarella started Hadoop to solve scalability problems they had with their open source search engine software, Nutch. Then Yahoo saw the work they were doing, realized it would be useful, and hired Cutting to develop it further. Soon, other companies like Facebook and eBay joined in as well. Today, Hadoop is used by countless companies to crunch data, and several commercial outfits have sprung up to support and develop the software and its ecosystem.
There are a nearly endless number of open source projects that have evolved along similar lines, including the Apache web server, the Ruby on Rails programming framework, and, of course, the Linux operating system. But in recent years, we’re seeing many old-school tech companies– companies that predate the recent open source revolution – use open source in very different ways. Now, companies like Microsoft, Cisco, and Salesforce are creating new open source projects, mainly as a means of promoting new or existing products and services.
But by adopting open source projects, will it really make the training of your team hard? Well, it really depends on the type of project that you decide to go with. Your team’s learning curve will be high if you fail in the below metrics.
Choosing the type of OSS
There are different types of OSS; it can be as small as a plugin, or a small library to the enterprise application itself. So if it’s a library or plugin, which performs one or two functions, or features in your product, it is really advisable to go with it. Because, if you need a small modification or something to be built on top of it, not much training is required — unless it’s a poorly rated library.
But if you want to go with big enterprise software, you need to think more than twice before adopting it. If you’re selling a product, it’s advisable to build from scratch, so that you will have more control over it. If not, if it’s for internal use, you can clearly go for OSS — no matter how bad it looks or behaves, only internal employees will be using it.
Developer’s mindset
Many developers will not wish to work in a legacy code base. They always prefer to start from scratch. But if they are exposed to a legacy code base, on top of some other OSS, they won’t be pleased. Definitely, the learning curve will be more because they need to understand the current system, and on top of that, they need to understand the OSS codebase as well and how it’s tailored to the current system.
If the OSS is a famous one like Hadoop, where the support is enormous and the developer community is quite active, you will have more developers who are exposed to the software and you will definitely get skilled professionals to tailor it to your needs. But if the OSS is not famous, your team will face a greater learning curve.
Be prepared for patches and updates
Updates and patches will fly continuously if the project is active. Software is never 100 percent perfect and as it is OSS, the team availability will be less and bug fixes won’t be immediate. So you need a lot of patience, and there is the possibility that a bigger update will roll out as well, which you should not let affect your tailored modules. On those occasions, your team’s learning curve will be high.
As discussed previously, software support really matters. There are a few OSS companies who provide support for free or for cost as well . This helps to keep your development cost and the learning curve spike to a minimum. But if the support does not exist, you have no choice but to be patient with your tech team. They really need time to understand the system and tailor it.
About the Author
HariVigneshJayapalan is a Google Certified Android app developer, IDF Certified UI & UX Professional, street magician, fitness freak, technology enthusiast, and wannabe entrepreneur. He can be found on Twitter @HariofSpades.