In some enterprises, open source is a bad word. In many others, it’s an unknown. While it’s difficult to determine the install base of some code because of the nature of open source software (OSS), seemingly only a handful of companies are consciously deploying OSS. However, you may already be using these solutions in your department without realizing it. Read on to find out how open source may have made its way into your department, and how you can benefit by moving forward with the open source trend.

Open source self-test
Answer the following questions to see if your department is using open source software:

  • Does your team use Mozilla Web browser, Linux, Apache Web server, or MySQL?
  • Do you use gcc or g++ for compiling?
  • Does your team build executables using make?
  • How about the Bash shell, grep, gzip, sed, calc, ed, Emacs, Finger, or uucp?
  • Do you use CVS or Bugzilla?

If you answered yes to any of these, your team is already using open source software utilities to get its work done. True, most of the items on this list are UNIX tools, but open source software pops up in other places:

  • Do you use Perl or PHP? Help yourself to the source code for these languages from the CPAN Perl Source Code page and the PHP Downloads page.
  • How about IBM’s WebSphere? As Roy Hoobler pointed out in his recent article “Apache: More than a Web server,” WebSphere and many other proprietary systems take advantage of open source software to provide quality solutions.

Still not convinced you’re using open source software? Don’t forget, open source doesn’t necessarily mean free—read this recent news from ZDNet to see Microsoft’s take on the movement: “Ballmer: We’ll outsmart open source.” When the big guys start to listen (and even agree in a limited fashion), it tells me that open source is prevalent enough to constitute a new competitive frontier.

How did it get there?
So if you’re worried that your team is dangerously infested with OSS tools that your developers depend on every day, it may be to your benefit to understand how it could have happened.

When people get together and donate their time and effort to create a product, there’s really only one reason: necessity. Perhaps the tools they use at work are inadequate or don’t do exactly what they’re supposed to do. Maybe someone’s pet project got too big to maintain, yet they want the work to go on. Perhaps a useful tool that would facilitate getting work done doesn’t exist. All these reasons explain why open source solutions might have made their way onto your network.

When your company’s budget and timeline don’t allow your developers to create the tools they need, your developers will still find a way to make their lives easier. For example, suppose someone went home from the office and wrote a utility to help them get their work done. The tool was useful to others, so it was tweaked a bit here and there through a collaborative online effort, and the person brought it into the office to use. This is one way in which open source projects can get onto your network.

My point is that necessity truly is the mother of invention. Your department had a need for something that either already existed and was readily accessible, or that one person couldn’t create entirely on their own. The means to create it in-house didn’t exist, so the solution was found through another means: open source.

You have to realize one thing: You may know what products your team will use, understand the nature of service-level agreements, and where you can get the best vendor discount, but your developers know what works. If something doesn’t work, they fix it. That’s what software engineers do. Developers are the number-one entry point for open source software in any organization. Using products that work (or that can easily be made to work) is a good thing all around, regardless of where they came from.

What should you do about it?
So now you’re faced with a business decision: What do you do about it? If you’re a control freak and you have to have a contract and guaranteed technical support for each and every piece of software, you can stop your developers from installing software on your network. That’s not going to last too long, though. Productivity and general morale will decrease significantly whenever you add new steps to any process, and restricting access will only weaken your employee’s ability to get the work done.

Your other option is to look at OSS as the business opportunity it is. If your team is writing software, why not give them a tested foundation to build upon? Do you really have to write everything from scratch? Chances are that a lot more people worked on an open source product than you’ve got in your department. If your own people are evaluating a solution, there really is no more risk than creating the software all by yourselves.

Furthermore, if your developers like a tool—CVS, for example—that challenges even the most expensive solution, why not let them use it? It doesn’t cost you anything, and you might even increase the possibility that new hires will know the product. I know a lot of Microsoft shops that think there’s no place for open source in their organization, but the truth is that there are inexpensive and free alternatives out there that can compete with proprietary solutions.

So the real question is, why would you accept risk and costs when you don’t have to? Open source software gives you the ability to customize a low-cost solution to meet your particular needs. As I’ve shown, you’re probably already using OSS. The smart business move is to evaluate how you can extend the use of open source solutions to your advantage.

Do you use open source?

Are you moving toward open source in your department? Why or why not? Post your response in the discussion below, or send an e-mail to our editors.