Menu
Free Code For Sale: The New Business of Open Source

Free Code For Sale: The New Business of Open Source

Figuring out which open source software packages are for you is still mostly a DIY proposition. But there are a few general frameworks out there to guide you.

The ROI of Trust

For his part, Roesch believes that the Snort community will survive. "Check Point needed education about why it's important to keep it open, and they get it," says Roesch. Part of that education was that the open source development model creates relationships between project owners and users that cannot be duplicated in the proprietary world. "A lot of the guys buying Sourcefire software are people who started using Snort in college, and now they're bringing it into their companies," he says. "It's hard to quantify the value of being able to go into a sales meeting against big vendors like Cisco and having someone [from the prospect company] ask for your autograph."

But that relationship, based on mutual trust and forged over many years, is fragile. If Check Point were to shut down Snort and close the source, says Roesch, "you would lose the goodwill of the community overnight.

"Getting these people's trust takes years," he adds. "Losing it takes minutes."

SIDEBAR: Your Guide to Open Source Business Models

OPEN SOURCE + SERVICE

What it means: Companies sell support and services around open source software.

Who's doing it: Compiere (ERP), JBoss (middleware), Red Hat (Linux)

Advantages for CIOs: You pay only for support, not software. The cost to switch providers is relatively low because the source code is available to anyone.

Start-up challenges: Difficult to build businesses because switching costs are low, as are barriers to entry. CIOs will always favour large, established vendors over start-ups unless the start-ups also control code development. Hard to get venture funding because venture capitalists are looking for sustainable competitive advantage in their investments. Unless the software is complex or mission-critical, CIOs may choose to support it themselves.

MIXED

What it means: An open source code base with proprietary add-ons.

Who's doing it: Sourcefire (security), SugarCRM

Advantages for CIOs: CIOs may not need the proprietary stuff, but if they do they'll already have acquired deep experience with the open source product before buying the add-ons.

Start-up challenges: There's ample motivation to make the open source product inferior to the proprietary package, transforming the open source into trial software. If that happens, there may be a backlash among open source developers and users wanting to see all the code.

OPEN SOURCE + BUY OFF

What it means: Companies offer a proprietary licence for their open source software so that users can modify the software and redistribute it without having to make the code changes available to the public.

Who's doing it: MySQL (database), Sleepycat (database)

Advantages for CIOs: The open source software has all the features of the proprietary version.

Start-up challenges: Sales of the proprietary version are limited mostly to those companies that want to redistribute it as part of their own hardware or software packages.

OPEN SOURCE + AGGREGATION

What it means: Companies assemble various open source software packages into integrated units that are easier for CIOs to consume.

Who's doing it: Exadel, Navica, SourceLabs, SpikeSource

Advantages for CIOs: Simplifies open source integration and support.

Start-up challenges: Barriers to entry are low, brand differentiation is difficult, lack of ownership of open source projects limits the influence of the company in the development of the code.

OPEN SOURCE + HARDWARE

What it means: Hardware makers use open source as the foundation for the software that runs their machines.

Who's doing it: Cisco, Digium, Netezza

Advantages for CIOs: Lower prices on hardware.

Start-up challenges: It's difficult to differentiate on hardware alone, especially when CIOs are looking to standardize their infrastructures.

SIDEBAR: Your Open Source Checklist

Open source software has to meet all the usual criteria that dictate software success . . . and then it has to meet some more

  • The Licence. The most restrictive open source licence is the General Public Licence (GPL), but it applies only if you intend to modify the software and redistribute it. Vendors have to make the source code for their changes available or work out a deal with the copyright owner to be released from the GPL. (The Free Software Foundation, which developed the GPL, is now in the process of revising it.) If you have no intention of distributing your modifications to software governed by the GPL, or anything integrated to it, then GPL is fine. But if there's any chance you may distribute it outside your company, you should purchase an indemnified version.
  • The History. If the open source project is just getting started, it may not survive. The developers' initial enthusiasm can wane; the software may encounter bugs that can't be fixed; users may abandon the project if something better comes along. You don't want to end up with an orphan product, unloved and unsupported.
  • The Community. Most successful open source projects have a leader who is respected by the developer community and is willing to delegate important pieces of the work to others. Delegation creates a healthy environment that attracts new developers. Look for projects that have a clear process for joining the community, for managing the project and for making contributions. Find the central communication core for the project (a message board or e-mail list) and read the history.
  • Code Ownership. Companies are more likely to attract capital and build trust with customers if they own the copyright to the code they support and their developers are the project managers and primary contributors to the code base.
  • The User Community. Projects involving complex software need big, active, happy user communities. Big communities mean that the software is filling an important need and that it works well enough for users to invest time trying to make it better. Small, unhappy user communities usually mean the project is poorly managed or the software is flawed. Again, check the main discussion board.
  • The Coverage. Open source thrives only when it is attractive to a large group of users. That's why the most successful projects have been platform applications that can be used in virtually any company. Industry-specific or niche applications do not attract large communities.
  • How It Integrates. Open source is usually designed to fill a specific gap or fix a specific problem, often without concern for how the software will play with others. Check bulletin boards to see if the project's developers are open to solving user integration problems. If they're not, tread carefully.
  • Commercial Support. This is one of the better indicators of a project's health. For CIOs who cannot afford to devote staff time to support, a robust commercial support ecosystem is critical.
  • Your Costs. It's easy to get carried away when something is free. Normal due diligence for open source is still in order because implementation time isn't free.
  • Proof of Concept.Don't overlook open source just because it doesn't scale or have all the bells and whistles. It can make a great testing platform or a proof of concept for a larger project that will use proprietary software.

SIDEBAR: Who Makes Open Source? You do!

As open source software becomes increasingly important to the corporate infrastructure, IT staffs are beginning to contribute to the code bases - not just at night and on weekends but on company time. Barry Strasnick, CIO of CitiStreet, a benefits management company, sometimes turns his programmers loose on the open source Web server program Apache - if their work has a direct benefit for the company. "We will do it on an ad hoc basis," says Strasnick. "It has to be a small project, and the benefits have to come back to me in six months, not 18."

"The quality of open source has become so high that there is now the incentive for companies to pay the staff to work on them because they reap the rewards," says Lee Hughes, CIO of Owens Forest Products, a manufacturer of interior doors and flooring. Hughes is working with open source consultant JasperSoft to rebuild Owens' business intelligence system on top of open source software, including JasperReports (open source BI software), Tomcat (an application server) and Postgres (a database). But there are key pieces missing - namely a set of generic user interfaces and business rules that link to the open source infrastructure. "It's basically turnkey except for those pieces," he says. Hughes's staff is tiny (three or four programmers), but as he expands to five or six in 2006, he wants to devote one programmer full-time to R&D - including contributing to open source projects. "Tomcat and Postgres cut our development time for this project by a third," he says. "If we had those other pieces, we could cut it by another third. It pays to have a hand in the outcome of open source."

The open source model is becoming so popular among CIOs, claims Strasnick, that they are banding together to do open source development that no one else wants to touch. Strasnick says these groups are mostly formed around work that no one in the open source community is volunteering for but that would help CIOs improve productivity. "There are things I need, but people in the community think it's too boring to work on them - like Unix utilities or an open source Cobol," he says. Large corporations are contributing to these kinds of projects, says Strasnick, but they're doing it anonymously for fear of alerting hackers to what's in their software infrastructures.

"The open source community is bigger than we can see," says Strasnick. "I would fund an open source community if I had to."

SIDEBAR: Open Source Yardsticks

Figuring out which open source software packages are for you is still mostly a DIY proposition. But there are a few general frameworks out there to guide you. Most offer obvious recommendations like "make sure there's good documentation", and all are untested and lack objective data about actual open source projects, but at least they capture some of the unique issues involved in considering open source. Here are some sources to try.

• Capgemini OSMM: www.seriouslyopen.org

• Business Readiness Rating for Open Source: www.openbrr.org

• The Navica OSMM: www.navicasoft.com/pages/osmm.htm

• How to Evaluate Open Source Software/Free Software (OSS/FS) Programs: www.dwheeler.com/oss_fs_eval.html

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about ApacheCheck Point Software TechnologiesCiscoCisco SecurityDellDigiumDrakeForrester ResearchFree Software FoundationGartnerGTEHewlett-Packard AustraliaHISJBossMicrosoftMySQLNetezzaOracleRed HatSlashdot.org

Show Comments
[]