Convince Management that Open-Source Projects are Safe to Use

Question

My bosses are old-school IBM'ers. To save development time, I've mentioned a few open-source projects that we could undoubtedly take advantage of in some new web applications we are building. They are always hesitant and uneasy about using anything like this (even jQuery).

I think the biggest problem they have is that they feel it is "too good to be true" to have all this free code (that is amazingly useful) at your disposal. Back when they were programming on the mainframe, open-source was pretty much unheard of. They additionally feel there is some sort of dependency that we will have if we use anything like this. Paying for something from a third-party makes them feel so much more comfortable. In short, they are stubborn in their ways (perhaps rightfully so).

What can I do to convince them that it is becoming standard practice to take advavtage of open-source projects when it is clearly beneficial to do so?

Answer 1

Fix their understanding of what "open source" really is. jQuery for instance isn't just a bunch of people throwing code together - it's a managed effort by highly-qualified developers. The code that is accepted is peer-reviewed by professionals in the field, and tested in many thousands of scenarios.

While open source software is often times thought of to be "free," that isn't always the case. Many groups and organizations simply use a different business-model that doesn't charge for the product itself but instead for the potential support. This works very well for some organizations.

Point out that many organizations like Google have been using open source technologies for years. Linux, "that free operating system," is one of the most widely used operating-systems used on corporate servers today. MySQL, the "free" database engine is enormously popular even with companies like Yahoo and can support many terabytes of data.

Answer 2

For something like jQuery, give them a list of some of the big sites that are using it. If you could find a competitor that was using it that would be even better. Show them some of the cool UI features that are already part of jQuery and give an estimate of how long that would take one of your in-house developers to create. See if you can get them to allow jQuery on a small test project as a trial run.

See here for some sites that use jQuery. I'm sure you could find similar lists for other open source projects.

Answer 3

Part of any OSS proposition into a commercial environment is a detailed legal check of the fine print, JQuery has 2 different licenses that it can be adopted under - but many OSS projects have less commercial facing terms that also prevent the use of those tools and code within your 'new web application' that you mention.

To convince them to take advantage you need to ensure you are on a firm legal footing in using the tool, and then express the cost-benefits - how much time does it really save you? can you quantify that in monetary terms - but be balanced and also express the negatives - it is not always roses and any attempt to present it as such will always be viewed with suspicion of deliberate bias.

Answer 4

"How to Win Friends and Influence People" has some suggestions that may be worth reviewing, with particular attention to the "Twelve Ways to Win People to Your Way of Thinking" and "Be a Leader: How to Change People Without Giving Offense or Arousing Resentment." Showing some empathy and that you do listen to their problems may go a long way to resolving the problems you are experiencing.

"Blog of helios" sometimes has some good suggestions for enlightening people on OSS, too.

Answer 5

Have a look at this two-year-old Forrester Report summarizing the widespread and accelerating adoption of open-source apps in the Enterprise. This Rpt has some nicely displayed summarized responses from corporate IT Depts, e.g., "why did you choose open source?" and "what are your primary concerns about o/s?"

• as that Rpt shows, open source apps are not just ubiquitous in the Enterprise, but they comprise a substantial fraction of the IT infrastructure (Apache, Linux).

• Regarding reliability for mission-critical applications, there are some recent high-profile instances in which blue-chip proprietary systems driving mission-critical apps have failed and been replaced by open source systems, e.g.,

• State of Texas election systems, an $863 million project w/ IBM, in which IBM was fired after repeated failures and concomitant data loss;

• London Stock Exchange replaced the Microsoft .Net system that runs its trading platform, in favor of the GNU/Linux-based MilleniumIT system.

(Both of these w/in the past year.)

Answer 6

Get into the corporate mindset and attack from within with something finite and low risk. Whether it's your direct management, or further up the food chain, there's someone somewhere worrying about money and schedule, and if you can sell your idea on money and schedule, you're likely to have a lot of success.

This is the general process I've seen be successful:

1. Start from experience - pick 1-2 (at most!) open source products that would be strongly beneficial to a project you're working on. Ideally, this is a new project, or new big feature in a big project, that can be segmented to avoid lots of rework. Pick open source products that are very mature with long records of successful adoption on big products. Even better if the open source shows a longer life than a competitive 3rd party product.
2. Do estimates - how much work is open source likely to save over alternate solutions? Get some numbers in manhours and also a sense of schedule. Also get numbers for how often new releases are delivered by the open source community. It might also help to know how many bugs are fixed in each release (especially if the bug fix is trailing off, which suggests maturity), and how frequenty interfaces are deprecated - since management may be afraid that the project will be dependant on something where you are forced to rework frequently and heavily.
3. Get the legal stuff - grab a copy of the licenses. If you can, get a friendly consult with someone in legal. Having the legal department on your side is a big deal here. If they agree you are safe, your management is a lot more likely to be OK with this.
4. Have a backup plan - Research options for the open source version of "tech support" - both the free community sites available and also the costs of hiring an expert consultant, if things shoudl go really bad. Generally, I think a case can be made that an open source consultant can actually be cheaper than a maintenance contract for a 3rd party product. And it's good to know that in the event of emergency, there is a "throw money at it" potential answer.

All that data put together spells maturity. It's a strong case today that open source projects are as big, stable, and reliable as a solid 3rd party vendor with a good track record. But your management won't get it if they don't see the data for themselves.

A good place to start is a small, wacky project with a small budget and little financial risk. That's another reason to start small. With 1-2 carefully chosen open source components, you have a shot at getting management to dip a toe in the water. If they are deluged with 20 open source requests, they may be likely to clam up in terror.