Back in the late ‘90s when we all first started thinking about using Open Source in the Enterprise – Linux as the first foray for many of us – our concerns revolved around support, skills and adoption.
Could we be confident deploying critical applications (or perhaps any) on an O/S that was supported by a community – instead of a vendor with a tech support line? Would our already over burdened IT developers become plumbers – building fault tolerance, load balancing and pooling into bare bones J2EE application servers – instead of focusing on business solution development and delivery? Finally, would the application vendor community port their applications – that we all depended upon – to Linux?
Then companies like Red Hat came along to offer versions of the Linux kernel and O/S with support. Support for installation, run-time and more importantly, keeping up on the legions of updates. Sure, we had to pay for it, but the cost was minimal compared to proprietary solutions.As for adoption, now the open source community is huge, offering the smallest of widgets to full-scale office applications, application development environments, databases and application execution infrastructures.
Unfortunately, the thing that drew us all to open source in the first place – cost – as in cost containment – is rearing its darker side – financial risk. Or, perhaps better stated, perceived financial risk with the specter of lawsuits and patent infringements.
Of course along with risk for some, comes opportunity for others. There is an emerging market to protect companies from the inclusion of open source code whose licensing we may not completely understand. This market includes tools to scan your code for licenses offenses and even Open Source Insurance as offered by Open Source Risk Management.
Christopher Koch, Executive Editor of CIO Magazine has a great blog entry from 12.28.2004 separating fact from fiction regarding open source licensing and risks for enterprises. His blog is directed at companies (like the majority of enterprises) who are developing software for their own use, and not resale or redistribution.
Adding to the open source rights discussion yesterday was IBM with their Open Source Pledge. IBM has promised not to enforce 500 patents that it owns – and will continue to own – against the developers of open source software. Of course, the same article points out that 500 patents is really a small number for the likes of IBM who received 3,248 patents in 2004 alone. And just to show that no “good deed” goes unpunished, InformationWeek reports that the IBM move was not purely a demonstration of its increased support for open source, but also an attempt to influence the political debate in Europe on whether software patents should be allowed, or if copyright alone protects the software developer. For more information see nosoftwarepatents.com. According to the InformationWeek article, IBM (as you would expect) stands on the side of adopting software patent law in Europe.
What does this all mean? Does the risk of open source litigation outweigh the cost, time to market, and collective intelligence advantages? It means (as in all IT and business decisions) you need to find the facts, analyze the implications for your situation, and when in doubt, seek the advice of (licensed and accountable) experts whose job it is to protect your business. But, do the work. Don’t let fear (alone) get in the way of opportunity.
James McGovern says
The CIO article had a second dimension that is less talked about. The fact that corporations are starting to develop software themselves and give away freely speaks to the fact that open source is long term viable for reasons not typically spoken. For example, Duke Energy just open source their .NET development framework. Likewise, we will be over the next couple of months also open source some code we have written as well.
Now for the hard part, getting analysts to start talking about this aspect of participation in the open source community 🙂