Like it or not, your company is probably using more open source software than you are aware of. In fact, if you are building web applications in anything but .NET, I would be surprised if you didn't use some open source framework or development tool in your custom application. You would be crazy not to. Companies that have not adapted to the existence of open source usually have what I call a "flavor of the month" architecture where the next application is built on what was written about in the last post on Slashdot or The ServerSide. I am not saying variety is a bad thing. There just needs to be a reason to use something different - like different requirements.
Here are some things that this company does to manage software in a world where open source exists. I have heard similar processes at other major companies that I have spoken to so this company is not unique.
- Define what open source is. They exclude Linux (which they consume like commercial software with support contracts and all) and open source software bundled in commercial products.
- Accept that open source is out there and has potential value.
- Sponsor a cross line of business open source review board. This organization is responsible for responding requests to use a new open source application.
- Manage a list of all usages of open source software within the firm. If you want to use an open source application, for research or production purposes, you consult the list for the software and version that you want to use. If you find it being used, you communicate your use to the "open source librarian." If it is not currently being used, you submit a request to the open source review board. They will tell you if there is a preferred alternative or put it on the list.
- Publish a handbook explaining the policy and processes around open source software.
- Standardize on some core frameworks. This will reduce maintenance costs and help with interoperability. Again, homogeneity is not the goal. Especially in a web services world, applications do not have to be built on the same platform. You just need a better excuse to deviate from the standard than "I wanted to see what all the hype was about for Ruby on Rails."
- Get to short lists of components quicker. It is easier to select from a list of pre-qualified options than comb source forge or Freshmeat every time you want to use a component.
- Reuse your understanding of licensing implications. There are many open source licenses and some play better together than others.
- Identify internal experts. If you know that an application was built on a technology, you can ask the developer who built it what they thought of the technology and best practices.
So, if your company is using open source software (and, chances are, it is) it is best to get a handle on what is being used and how.