Software Configuration

for an open source world

Introducing Open Source Software into Your Company

software configuration management open source


Often we find ourselves wanting to introduce our favorite open source tool to our companies and/or clients. In many companies, this is not an issue. However, in a few companies there are concerns whether real or perceived that can halt any progress in introducing new software. I'd like to provide a few insights and maybe help anyone experiencing issues introducing an open source product within their own company. Believe me it is possible to bring in open source software if you back it up with lots of reasons and benefits!


First, what is open source? Open source software has been defined by the Open Source Initiative to adhere to the following criteria. Contrary to the name, not only is the source code available, but the software must adhere to 10 different requirements to be considered "open source".  Most companies use open source software whether they know it or not.  Some examples of open source software are Linux, the Apache web server, Glassfish, SAMBA, Subversion, CVS, Eclipse, etc.


Why would a company fight open source software? Well, that is a good question.  I believe that the problem started with the highly public SCO lawsuit against various Linux vendors over the last couple of years.  SCO claimed that some of their proprietary code in the UNIX System V code made its way into various Linux kernels and brought lawsuits against these companies.   The amount of damages requested was on the order of billions of dollars.  In addition, many commercial software companies like Microsoft made it a point to sell their software as being indemnified from these risks.  That was enough to scare the briefs off of many legal departments at some of the world's higher profile companies.  The last thing these companies wanted was to become a target of SCO or in fact anyone else's extortion attempts.


Example

So let us say you found an invaluable open source software tool that you would like to introduce to your client.  Since this site is dedicated to software configuration management, let's use the popular version control tool called Subversion as an example. Your client, Client X, states that they really would like to dump their expensive and time intensive 3rd party version control tool, and the engineers are familiar with Subversion and excited about the prospect of using it for real work.  However, management is concerned that the legal department will say "no" because of legal risks they see after reading last year about SCO's legal wrangling.  Yeah SCO is defunct, but how many other SCO's are out there in waiting? Your manager is concerned that when the software breaks they wont be able to call anyone, and the sales guy for the expensive 3rd party version control tool is taking the VP out for a game of golf to tell them how bad open source is for business.  Yikes!  Where do you start?


Issues


 So what are the forces we are working against here?  Depending on the specific environment, you will need to work your way more or less t/hrough the following hurdles...


1.) Technical - Always make sure the product you are introducing has real tangible benefits.  Learn the tool inside and out.  Join forums to see what issues other folks are experiencing.  Also, don't forget this tool needs to integrate into the existing customer's environment.  Learn the customer's environment even more than the tool you are introducing.  A bad integration can make you the most hated person in that company, or maybe even get you fired.

2.) Competition - If there is existing commercial software ask yourself if you think the current software's sales guy is going to sit there and let you introduce open source software?  No No and No!  Expect a fight on this end, make sure the person making the decisions knows what is at stake and how much money you expect to save them and be sure to provide all of those other benefits from the technical side (see #1).

3.) Legal - The company that you are introducing open source software wants to be sure they are indemnified against all sorts of risks.  Make sure you can address all of them.  I'll provide some help with that soon.

4.) Inertia - Inertia is always an issue.  Find others that will champion the open source cause and make sure they are vocal about it.  Hold lunch sessions to educate folks.  Eventually, the change will happen and the software that you wish to introduce will be accepted as a viable option.

5.) Support Concerns - How will the software be supported? Will it be from in-house expertise or an external third party? Be sure to figure out those costs when presenting your proposal to management.


Solutions

Next, let's try and address some of these issues discussed earlier.


Technical Issues

Let's face it.  Knowing what the open source software does, how it does it, and every little idiosynchrosy is central to getting acceptance.  Here are some questions you may want to have ready, and without a doubt there are more.  Please think this through, because this is key to you becoming the champion of the new software and training others to also pick up your cause.  


1.) What features make this open source software superior?

2.) What variation of an open source license agreement is in place?  Do you understand the limitations the license places on what you can or cannot do with the software?  If you have questions newsgroups, commercial support companies, and contributors for the open source project are the best folks to go to for information.

3.) How well does this software work with other software that may be in place at your company?  Again newsgroups might be a good place to ask for advice.  Many open source projects have spawned other projects to address integration issues with common projects.  Subversion is a good example where there are plenty of other projects that are created to make sure subversion works well with Eclipse, Windows, and many other tools.  Other open source projects often spin off many helpful peripheral projects.

4.) What type of hardware is needed to support the new open source software?  Do you need a lot of physical memory, hard drive space, etc?

5.) How vibrant is this open source community?  Do technical features get added frequently?  Do bugs get fixed?  Will you need to fix the bugs yourself?  The robustness of the community often translates into stronger code, and wards off the impression that the code is "buggy".

6.) Use your imagination for more questions.  It is useful to think of everything, so when you are in that meeting with the management or other engineers, there are no surprises.





Competition

Competition will be different at every company.  My recommendation here is to know who makes the decisions.  Send this person technical papers (Performance, market shares, etc). Copy them on emails of glowing recommendations about the software from other engineers from within your company and at other companies.  Talk to other companies.  I found this useful to help shake the impression that open source software was maybe too bleeding edge.  If you are at a big company, find other big companies that use the software and get feedback.  If you are at a small company do the same and preferably in your same field.  Help the manager relate to how this software will impact their future business, and make them feel good about any decisions.  You will also find many others within your open source community that are willing to help out with this.

If there is existing software that you are trying to replace with an open source product, figure out who has a stake in keeping that software at your company.  I find that sales guys are good at building walls.  Break down the walls with your own demonstrations.  Recruit others at your company to help create grass roots support.  Talk about the software every chance you get, and be your own sales force!  Also, if there are companies that support this open source product, go to them for help.  Your company may find that their support is superior and costs far less than any fully commercial alternatives.

The other folks, who will be tough to compete with, would be the in house support staff of the existing software you are trying to replace.  Lets pick on Clearcase for a bit.  IBM owns Clearcase, and many of engineers have made careers (my former un-rehabillated self included) out of managing Clearcase servers.  If you are trying to bring in Subversion which comparatively requires much less maintenance, there are going to be several guys unhappy if management makes that decision to use Subversion.  That is where the uphill battle occurs.  These folks will be quick to point out any issue, since they want to fix Clearcase servers all day.  Is that good for the company?  No, of course not, but this is what you will need to address if you are trying to replace commercial products with an open source alternative.  You will probably never convince these guys of an open source alternative, so just keep a chin up and work around these guys until management forces them to leave or learn your open source alternative.



Legal

You may need to appease the lawyers.  If you are at a company that is insisting that they purchase indemnified software (this is not a bad thing), you will need to address several points.


1.) Commercial software is not always indemnified.  Yes its true!  Not all companies check for this, so don't think that just because a lot of money is involved for commercial software that it is necessarily safe.

2.) Many open source communities have companies that will provide support for the open source solution which does include indemnification.  The JBoss group indemnifies the JBoss servers with a contract.  Other open source support companies do as well.

3.) You can purchase open source risk management insurance.  Yes, there is such a thing!  One company that has made a niche of this is Open Source Risk Management.  There are other companies venturing into this business too.



Inertia

Inertia is a difficult issue to overcome at larger companies.  You can help overcome the inertia, by following the previous advice of becoming your own sales force and generating some grass roots support for your product at your company.  Eventually, developers, engineers, and other technical staff will start asking where the new software is.

Also, make it easy for the decision makers to make their decisions.  Build an environment of the software that you are proposing to use.  Integrate it with other systems if necessary.  Nothing helps make progress more than seeing a real working environment!


Support Concerns

Support will be a major concern for the decision maker at your company.  Management wants to know that when an instance of the software has a bug, they will be able to call someone and get a fix ASAP.

Here are some things you may want to consider.

1.) When choosing an open source product and it will be central to your day to day work, make sure there is a vibrant open source community.  In this respect, I mean a community that is making frequent fixes and new releases.  Also, find a community that you can ask questions.  This is key.  You do not want to get stuck in a situation where there is no help available.  

2.) Find companies that support your open source communities.  These companies often offer support packages.  Even when purchasing support, your open source alternative will often cost much less than a commercial product.  These companies are invaluable to selling their services too.  They will help you introduce your open source product, and have a lot of experience doing that.  Use them as much as possible!

3.) You may know an open source product so well, that you may be the support.  You may even be able to convince your company to allow you to support the open support community by making changes back into the original source code.  Bravo!  



Conclusion


Open source software is the way software is being built.  There are few commercial products out there that are staying competitive doing business they way they were doing business 20 years ago.  Technically, the reasons are compelling for strong open source software communities.  However, business and legal concerns do not keep up with the times.  It is your job to educate and enlighten.  Now go forth and prosper!




Bookmark and Share