OSS ADOPTION MODEL
Free. The word that attracts most people to the open source world. While Open Source Software (OSS) gives you the freedom (as in free speech) to do whatever you want with the code, most people, at least in the early part of the OSS journey, are attracted
to the more "tangible" freedom, as in free stuff!
Traditionally, OSS has seen a bottom- top adoption model, wherein an engineer sees a cool open source solution that he believes can solve a problem and suggest it to his team. Off late however, a more top-bottom approach is increasingly being seen wherein the management, aware of the value that OSS can bring to the table, drives adoption.
As a team adopts an OSS solution and    customizes it according to their needs, they get a better understanding of not only the software itself but the OSS philosophy also. They may feel inspired enough to push some code back to the community, thus shedding the mere consumers tag and moving into the contributors' category. The OSS spirit is starting to take shape in your organization!
Encouraged by the success of OSS solution in one project, an organization may feel tempted to adopt similar solutions in other projects; not only within the organization but may start recommending it to clients as well. The management starts to get involved and actively start looking for areas where they can adopt an OSS product and build solutions around it.
OSS adoption doesn't need to be limited to in-house projects or developing bespoke solutions for clients. Some of the more liberal licenses (see "Some more open than others") allow you to take an OSS product, build a commercial product on top of it and sell it at a profi t. Many shareware utilities are nothing but GUI wrappers around open-source command line packages.
Of course things are rarely as simple as a line on a graph and you might face multiple diffi culties along the OSS adoption path. Like in any other sphere of life, while some products can be a joy to work with, others may leave you pulling your hair out. Worry not. Our aim is to help you get started on this journey and discover that while the OSS world may baffl e you at times with its peculiarities, it can be a very rewarding journey in every sense of the word.
SELECTION PROCESS
How to identify an OSS solution that fi ts your need?
IDENTIFYING REQUIREMENTS
Before you start looking out for an OSS solution (or any solution for that matter), it is important to spend some time preparing a list of requirements; i.e. trying to fi gure out what exactly it is that you need. The best way to do this is to look within the organization and getting various stakeholders (people who'll be using the said solution) involved in the process.
Break these requirements into two or three categories, depending upon the relative importance of the feature. The fi rst category, say, "must have", contains the features that any solution you zoom in on, absolutely must contain. For example, if you are looking to adopt a new collaboration tool, email and IM integration might fall in this category.
Next category of features would be "nice to have". As the name suggests, these are not as important as the previous category but which would make your life a lot easier. Allowing user to do a full text search within attachments would perhaps be a collaboration tool nice to have . The fi nal category, which we call "bells and whistles", are features, say, AJAX support, that may not add an additional functionality to the solution, but are perhaps a better way of achieving the same thing.
Of course, this is just a suggested classifi cation technique. You can use any other technique e.g. rating requirements on a scale of one to ten or anything else that helps you prioritize.
When you have two or more teams or individuals trying to fi gure out the requirements, arguments are bound to happen wherein everyone feels their requirements are on a higher priority than the others. A coordinator or a "devil's advocate" to ask people questions like "Do you really need this?" or "How will that help you?" goes a long way in keeping the requirements in check and ensuring you have a reasonable list of requirements at the end. Make sure that everyone feel represented in this activity and that in the end there's an agreement on the list and priority of the requirements.
MATCHING REQUIREMENTS WITH OSS PROJECTS
Once a list of requirements is agreed upon, you can start the process of evaluating the products themselves. Comparing the feature-set of the product with your list of requirements and choosing the best match might seem like oversimplifi cations, but it's a start. In case you are lucky enough to fi nd a close match that also fi ts your constraints (see below), go for it. More likely, you may fi nd solutions that almost live up to your requirements and others that match your requirements but do much more. While the latter may sound like a good problem to have (or maybe no problem at all!), once you install the product you may fi nd out that the features you do not plan to use are intrinsic to the product and end up adding a layer of complexity and confusion to the end-users that you could do without.
In case a product falls short against your requirements and there are no other real alternatives, you have the option of scaling back your requirements ("Do we really need this?") or, alternatively, bridging the gap on your own. This means getting your in-house IT team involved to develop the missing features or hiring someone from the outside. You can even submit the feature request to the core team of developers and hope they incorporate it within the product, but do not keep your business waiting on that—most projects have a roadmap of features planned at least six months in advance, and getting your feature in anytime soon, if at all, may not be realistic.
While we've discussed the business and functional aspects of the requirements so far, one shouldn't completely disregard the technical aspects while evaluating a product. A solution that perfectly matches your requirement but does not run on your current hardware or is based on a technology that your team is unfamiliar with may not always be preferable to a solution that almost matches your requirement but would run just fi ne on that old server you have lying around. You might be able to get the missing feature developed by your existing team of developers and still have cash left in the bank from savings on the server.
SOME MORE OPEN THAN OTHERS
Not all open source software are equal in terms of what they let you do with the code. While going through any open source project you'll fi nd that the code is released under a particular license and what you can do with that code is determined by the terms of that license.
These licenses have an impact on how proprietary or custom code added on top of the open source code is to be handled. Some licenses like that of Apache and MIT let the user mix open source and proprietary code without the need to contribute back, while other more restrictive licenses like GPL insist that any changes made to GPL code must be released back to the community.
In case you plan to modify any OSS code and incorporate some business critical code that you won't be comfortable sharing with all, you are better off looking at projects released under the more liberal licenses. Similarly, if you plan to build a commercial product around or on top of open source software, stay clear of the more strict licensed software to avoid any controversies.
OSS PROJECT SOURCES
So where to get started? There are dozens of places where you can fi nd open source projects that suit your needs, out of which Github, Source- Forge and Google Code are perhaps the most popular. Not only can you let the sites host the source code, but also offer other tools like Forums, Wiki, etc., that help the project community interact with each other.
A word on contributing your code back to the project. While most projects do have some kind of review mechanism in place, some projects are very liberal wherein almost anybody can submit patches or code that implements new features. Sites like Github that are built around distributed version control systems, take collaboration to another level by letting anyone "fork" (copy) a project, make changes and then send a request to the original project to "pull" your changes in. The reviewers of the original project can take a look at your changes, and if they like what they see, can commit your code to the main repository with one click.
OSS METRICS
Some basic metrics to help you evaluate various OSS solutions.
STABILITY
A well-established release management system is a good indicator of the stability of a product. Most products will have a roadmap that gives an idea about the near, mid and long term direction of the product. Looking at this roadmap gives you an opportunity to evaluate the goals of the product, and see if they are in line of their own.
If a roadmap tells you where the product's headed, one look at it's recent releases will tell you what the project's delivered. Go through the release notes to understand what the team has been shipping lately—adding new features or simply fi xing bugs. Another thing to look at is the frequency of releases. While an "agile" development may work great for a FTP client, you probably don't want to be updating the OS on your production box every two weeks?
A product with an average of, say, a release every three months is perhaps better than a product that sees no activity for two years, and then ships six updates in a month. Do remember that there can always be exceptional circumstances that can dictate the development lifecycle of a project.
QUALITY
This one is slightly trickier to evaluate without using the product. You can start off by looking up what kind of bug tracking mechanism the project is using. The name of the bug tracking solution that a project is using is not as important as the fact that they are using one!
Go through some of the recent bugs, without getting all technical, to get an idea of the frequency and quality of bugs being reported,and the typical turnaround time on most bugs. A critical bug, that lets a malicious user exploit the vulnerabilities in the product to take control of your machine, that has been sitting there since 2005, is probably not a good sign!
Now we are not suggesting everyone would understand all the technical details typically available on a bug tracker, because you don't need to. Common sense and a little bit of time spent on this activity can take you very far.
LONGEVITY
As with traditional IT vendors, how long you've been in business is usually (but not always, admittedly) a good indicator of how much longer you are going to be around to support it. Now we've been around long enough to know that success in the past is no guarantee for success in the future or that there's no such thing as too big to fail. However, it's equally important, to use another cliché, to watch out for the fl y-by-night operators. While a newly launched project may look promising, it's perhaps prudent to wait and watch if the core team of contributors is just as enthusiastic about the project six months down the line.
INSTALLED BASE
While you may not get an exact fi gure on the number of people using a solution, most products do feature a list of organizations using their solution. Some even feature case studies on how these organizations have incorporated the product into their setup. In case this information is not available, a simple look at the number of downloads the product has seen since launch is a good indicator as well. A larger installed base also means a larger community for you to turn to for support. Go through the support forums and mailing lists to get a feel of the community at large.
DOCUMENTATION
The bane of many OSS products, the importance of good quality, updated documentation cannot be overstated. Documentation is considered a pain by most developers, so you'll fi nd that quite often this part of the pie doesn't quite match with the rest of the project.
This problem is not limited to smaller, low profi le projects with limited developers or a small installed base. A project as high profi le as Ruby on Rails has been criticized for out-ofdate documentation. If you are going to be dependent on the open source community for help, make sure the solution you choose has up-to-date documentation.
Kunal Dua
Subscribe to this comment's feed
| < Prev | Next > |
|---|
