Open Source Software
Does it Work? Does it Pay? Will You Regret it Later? (March 27, 2009)
An introduction to Open Source Software
Open Source Software (OSS) is developed when the efforts of programming are distributed to multiple parties to create or improve an application. During this process, code is open to a wider development community to freely exchange ideas among a potentially vast knowledge pool. Successful applications survive by continually being developed while others, in which the communities are not interested, remain unchanged (and may be abandoned). Many firms are looking to solve similar business problems—therefore, so the argument goes, this approach may decrease the cost of development and increase quality, reliability and flexibility.
If a company develops a module that becomes popular in the OSS community, it may be further developed and the firm doesn’t have to pay for that development. However, this opens up the module to competitors. The converse though is if the firm keeps the module proprietary, it may not have enough resources to keep up with the development of technology.
The OSS community is unstructured, there’s no “marketing department” and there are a lot of undefined aspects. However, firms are finding ways to harness the OSS community to produce marketable products. In the past, the US government has approached OSS cautiously, but now that the country is looking for inexpensive solutions, officials see this as an opportunity to invest in open source and to foster innovation while drastically lowering operating expenses. Recently, there has been a trend for companies to look to OSS to fill “the gap between innovation and product…. Mark Driver, Research Vice President of Gartner, is quoted as saying that by 2011 at least 80% of commercial software will contain significant amounts of Open Source code” [emp. added].[i]
Hence, the landscape of OSS is changing dramatically. OSS is no longer an affair of hobbyists on the Internet who are messing around with some code. The OSS model is becoming an integral part of the software development landscape. The top concerns about Server OSS from companies and clients are: Security (65%), Availability of applications (65%), and Ongoing support costs (51%).[ii] Hard dollar cost justifications are driving a lot of IT decisions right now, so if OSS provides a more attractive price, it is worth considering. As long as there is a strong “manageability platform,” i.e. a model that guarantees that the OSS won’t disappear and will be maintained, it is potentially viable. A firm that uses OSS without such support runs the risk of having to tie up valuable resources to seek solutions if/when the software breaks.
IT Executive Exchange (ITEE) considered similar questions: whether or not OSS is viable, is it secure given the fact that anyone can theoretically work on it, the extent to which companies in NE Ohio region are using it, what are the pros and cons of using it, and what the future holds for OSS.
Linux and Other Major OSS Products
In the current economic climate, 60% of respondents in the Feb., 2009 IDC survey were either planning (40%) or investigating (20%) to increasing their use of OSS operating system Linux on clients and/or servers. [iii]
Most firms attending the ITEE use Linux in house, and some embed Linux components in products to sell to customers. For some niches, Linux is considered superior to anything else on the market. As in the quotation above, one of the firms doing this does not necessarily tell its clients that it does so. Another firm rolled out an application to an entire division based on Linux, experiencing significant costs savings, even for support. Linux is less support-intensive than any other operating system software, in the view of one firm present.
A subscription with Red Hat (www.redhat.com) provides ongoing support for Linux solutions, but as one firm reported, this support is rarely needed. Red Hat, which now sells a lot through channels (value-added resellers incorporate it into their products and offerings), keeps the licensing clean (because the risk is shifted to Red Hat). A software development company cannot simply use Linux and resell it to a customer; intellectual property laws require the sale to include a license. Some argue that with more business intelligence (BI) lining up with firms like Red Hat, you are no longer working with OSS, it is now proprietary software. Also a company should be careful to make any OS changes under an agreement with a firm like Red Hat because changes may void any warranties or support contracts.
Oracle now has support for Linux (Oracle Enterprise Linux, OEL). In the view of one participant, Oracle charges a lot less than Red Hat for comparable support services. The big players now have to pay more attention to the OSS space, particularly at the OS level. IBM has tied AIX, its version of Linux, to its hardware for optimal performance. BEA’s LiquidX (the thinnest possible JAVA-based OS) is an extremely thin OS implementation that is paired with client software for maximum efficiency. The open source nature of Linux makes it possible for it to be adapted to needs like this, and vendors once again have unique products to sell. When OSS is lined up with big vendors, it starts to lose its definition as purely “Open Source.” Big vendor support provides a certain level of assurance that it behaves as expected; in theory OSS code can be inspected but who has time to inspect it? And end users do not necessarily want to make changes that come in from the OSS community because Red Hat or other vendors may not support them. So can OSS be modified or not? It is becoming more murky.
It is necessary to pay attention to the OSS licenses (there are about five different types in use). You can’t resell the free software, but you can tell the user to download it himself. So charge for the additional stuff you have done and give the OS for free. Reselling Red Hat UNIX is fine; there is a model for that and prices are negotiated with Red Hat. Another participant tells his clients to download SharePoint from Microsoft, which is included for free with various server licenses, and then he sells additional software based on SharePoint
Regarding security, RedHat Linux has been evaluated on a quality scale of 1-7 at level 4 for use in DoD-type secure environments.[iv] While other variants of Linux (such as IBM’s SUSA Linux) have also been certified, very few other OSS products have.
Despite progress on the OS side, the client level is still brand-new ground, with a lot of uncertainty. Picking up on this point, another participant spoke about how his shop still has a great deal of legacy code that requires that they maintain proprietary software.
Pentaho (www.pentaho.com) is another open source solution provider with commercial and community versions. Pentaho BI Suite Enterprise Edition provides comprehensive reporting, OLAP analysis, dashboards, data integration, data mining and a BI platform. Pentaho's commercial open source business model eliminates software license fees, providing support, services, and product enhancements via an annual subscription. In the years since Pentaho's inception as the pioneer in commercial open source BI, Pentaho's products have been downloaded more than three million times, with production deployments at companies ranging from small organizations to The Global 2000. One of the ITEE participants noted that they were able to embed BI solutions in a product they offer by using Pentaho’s software. This was a very low cost way for them to deliver capabilities in their package that are not ordinarily seen in that level of software.
DotNetNuke (www.dotnetnuke.com) offers a lot of modules and plenty of support with free updates. (Two firms present were evaluating this.) It offers a framework for building websites and web applications on Microsoft ASP.NET. Using DotNetNuke, businesses can quickly develop and deploy interactive, dynamic public websites, intranets, extranets, and web applications. DNN Corp. provides this framework in both “Community” and “Professional” editions. One of the ITEE participants deals with clients who may have their own, hand-written, minimal content management systems, and the contrast with the 100’s of modules in DotNetNuke is stunning. This firm would rather its clients install DotNetNuke, because it makes things so much easier for this firm to work with the client.
The Eclipse Foundation (www.eclipse.org) is an open source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. The Eclipse Foundation is a not-for-profit, member supported corporation that hosts the Eclipse projects and helps cultivate both an open source community and an ecosystem of complementary products and services. One of the participating firms used Eclipse’s Eclipse Process Framework (EPF), a tool to model a very large knowledge base by drawing multi-faceted relationships from free-form text. They were able to publish a multi-dimensional taxonomy as a website based on the process modeling capabilities of this product.
Other Examples of OSS Use for ITEE FirmsEmbedding an OSS HTML editor in a product the firm sells to avoid developing one themselves
- Keypass for password vaulting
- Open Office
One participant related an experience at his company where they used an OSS version of a tool successfully for a while, but eventually hit a wall. The OSS version did not fully implement an international standard, but a commercialized version did. They opted for the latter. While the OSS was sufficient for a couple of years, they got a lot of value out of it, but had to switch. There were a few commercial versions that could go to. They were already able to see the business value of moving.
Another pointed out that just as firms such as IBM makes an investment in keeping their software products viable for many versions, so the OSS community is unlikely to walk away from valuable software and not keep it viable. And whether you get an upgrade you need from a big firm like IBM or from the OSS community depends on perceptions of the need for that upgrade, availability of resources, etc. You have to do your due diligence to see who is behind the software you are buying, no matter where it is coming from
A third consideration is that increasing computer power, in general, tends to make issues of scalability less significant. One person asserted that the size of the data sets could be more of a constraint that raw compute power these days. Another somewhat disagreed, relating the story of one firm whose software ties them down to older harder that cannot easily be upgraded. OSS, which may be newer and based more on non-proprietary components, may be more scalable in this sense. OSS may have more of a migration path.
Although the question of whether or not OSS will be supported comes up time and time again, one participant made the following argument. If there are firms that get value out of the OSS, and are therefore willing to pay something for support, there will be programmers out there who can be recruited to provide that support. One or two good “gurus” will crack open the OSS and do what you need done to make it work for you. Microsoft won’t do this.
Again, though, making the comparison to software from major firms, there are also huge communities out there willing to help with those programs. And how can you evaluate the qualifications of anyone you might hire for OSS support? The answer: apply the same vetting process you would to a VAR (value-added reseller). The more mature the OSS, the greater the breadth of support that is available.
Evaluating the security of OSS is no different than evaluating the likelihood of security problems with software from major vendors. Microsoft says that, because its software is used by governments around the world, it has been inspected by many governments and therefore should be considered more secure. Or, is it true that inspection by anyone of OSS will lead to more discovery of errors? One person asserted that there may be fewer errors in Wikipedia than in textbooks for this reason. If you are going to run your company on software made by two people in a garage, make sure you get a copy of it in escrow. A no less real threat than hackers is the threat that programmers will try to take advantage of you if you are naïve in the agreements you make with them.
OSS and ERP
The maturity level of open source ERP seems to be low. One participant thought that in five years, there will be more mature versions. Selling something like ERP requires clout of fairly large companies, since they involve so much for the firms adopting them. So they have to be well developed. Another participant pointed to the absence of a big player, such as Google, who is getting behind open source ERP right now. The competition is not there (yet).
Since many firms have SAP, the more it opens up, the more the OSS community may be able to help. The solution may be to “chunkify”; divide software into modules that the OSS community can work on. The bigger task is integrating modules after chunkifying because the customer will want one solution. ERP vendors used to offer their modules piece by piece; the move towards SOA and chunks may make that possible again, picking up customers that are not such large businesses. Chunkifying may also be correlated to the rise of cloud computing. And if ERP is becoming a commodity, then there may be room for the OSS community to develop it. Financials may be more headed to being a commodity, whereas something like supply chain is much farther away from that.
Since OSS is becoming more complex, it is more difficult to determine optimal decisions. The risk of taking the chunkified route is support—if you are doing the integration, you will do the support. Because each vendor/OSS may offer new versions, integration becomes an on-going problem, not something that is done once. (This integration issue pertains as well to OSS more generally. If you are getting one piece here and one there, you will do the integration! Open SOA is coming down the pike, and may make this task easier.)
Training also becomes a big issue. Only one-third of all ERP attempts are successful. The problem seems to be integration; you can hire an integrator, but that may fail too. Then you may try SAP. You don’t want to be penny wise and pound foolish. ERP is a product; it is not your core business, only a tool for your business.
Buying integrated packages may offer a means of reducing support costs. On the other hand, the OSS route may give the firm the chance to pick components and customize them so that they are optimized for that environment.
To OSS or not to OSS
Issues to consider before using OSS include:
- What is your core competency?
- Have you completed a detailed analysis of your business problem?
- Will the OSS provide you with cost savings and/or efficiency?
- How willing are you to manage first adopter issues?
These questions illustrate that the adoption of OSS is becoming a matter of business strategy. For example, Google’s Android platform brings together a number of open-source pieces that would not otherwise be available in such a convenient form. Android has little market share but Google is betting that the Open Source model will eventually allow it to overtake proprietary phones like the iPhone.
A new world is developing which some call Open Source 2.0. If before OSS really was based on efforts of volunteers, now some of these efforts may be paid. There are intermediaries who may pick up the OSS and commercialize it. It is becoming a new entrepreneurial channel for launching software, the potential success of which is first tested in the OSS arena. Firms that have developed proprietary code may choose to open it up and take advantage of the community out there, and firms that embrace OSS by providing source may, in a sense, take it back to being proprietary (de facto if not de jure). This does not have to be a one-way street—you can go back and forth. If you, as a firm, are unwilling to defend the intellectual property in your software, then you should look at opening it up.
Another model that was mentioned briefly was acquiring OSS from the U.S. government. Much of this code is available to the public, because the public paid for it (a license does have to be negotiated, but the cost is minimal). In one ironic twist, NASA spent a large amount of money developing some modeling software, a commercial firm picked it up and started selling it, and NASA ended up paying the commercial firm to use the commercial firm’s version and get their support.
But, not everyone wants to jump on the OSS bandwagon. One of the firms present is on the sixth iteration of its own custom CMS, which is heavily optimized for their core business. They have compared this to what is available in open source and find their own system to be far superior. The OSS tends to be rather piecemeal.
Another issue is scanning the environment to find appropriate OSS. One participant uses podcasts to keep up with possibly relevant developments. But the mature, secure, well-used, stable, and useful OSS seems to bubble to the top, and people find out about them. Otherwise, you may need to have the temperament of an early adopter in order to stomach some of the OSS risks.
Ultimately, software adoption comes back to showing the return on investment. If this can be done with OSS, it may be a good choice. Vendors and VARs will bring solutions, and these solutions may well include OSS components. Given the future potential roles OSS may play, it behooves everyone to become more knowledgeable about it. The large scale aggregator of OSS may be sitting around the corner—the Google of OSS may be coming!
[i] Björn Lundell, Brian Lings, Anna Syberfeldt (2008). “Open Source Software in Complex Domains: Current Perceptions in the Embedded Systems Area,” Proceedings of the Fourteenth Americas Conference on Information Systems, Toronto, ON, Canada August 14th-17th 2008
[ii] IDC’s Feb. 2009 Linux Usage Survey
[iii] IDC’s Feb. 2009 Linux Usage Survey
[iv] The speaker is referring to the Common Criteria, a system that is jointly run by the National Security Agency (NSA) and the National Institute for Science and Technology (NIST). At Evaluation Assurance Level (EAL) 4, source code is examined, and for Linux, every line in the approved version has been examined. However, when a patch is applied to the software, the EAL assurance is made void, unless and until the new version with the patch has been validated. Hence government agencies have a real dilemma of continuing to use older versions that a) may not have all recent functionality and/or b) may not have a patch to improve security. The Common Criteria system is currently being re-evaluated by the Obama administration.