In a few years viewing source code within the major components of software infrastructure will probably be a routine way of doing business. In the meantime it seems that the only reason managers want free software is because it is free (as in free of costs). That’s not a good reason in itself: in the long run there are compelling reasons that robust, mission critical infrastructure software should be made free software.

For over 5 years, we at OCI have been supporting free software CORBA products. Clients have been using them to build elaborate integrated software systems. During that time many of our clients have extolled the virtues of free software in regard to meeting their needs. The money to pay for software never came out of their pockets so clearly those virtues didn’t relate to price.

Free software slows ever-present market pressure to support only a single platform, or a very narrow set of platforms

It turns out the focus was on them being able to do a better job. If you have been wondering what the impetus is, for switching to free software, from a technical standpoint, perhaps the list we (OCI) have compiled over those years can help. The list breaks into fourteen categories but sometimes the benefits spill into other areas.

Configuration options and management

The focus here is on platforms used, compilers supported, etc.

Compiler or IDE choices

You have the source code. This means you can choose your compiler. Your ability to write highly portable code improves when you can create a development environment with a compiler that spans many platforms. Many proprietary products lock you into a single compiler, often linked to the hardware platform. Free software products often support multiple compilers that you can choose from. Keeping code portable keeps your options open.

Upgrade on your terms

If for some reason you do not want to upgrade the platform’s operating system, in lockstep with everyone else, you don’t have to. You can keep using previous versions and add patches or enhancements selectively. But be warned! Free software projects are often cutting edge. Later versions of the product may require a later version of the compiler for instance, as they stress the compiler support of programming techniques.

An obscure platform need

If you have a special platform that you want the software to run on, then do the port yourself, and create an affinity group within the community to help you spread the load on your maintenance activities. Don’t let someone else dictate platform policy for your organization. You don’t have to follow the crowd.

Are you a vendor who is feeling left out?

If you are a platform vendor and you find your platform is no longer supported in a technology area, or you think it’s poorly supported, find a free software solution and support it or sponsor it yourself! Give your customer base insight into how to tune the software to maximize performance. No longer will you have to worry about a software vendor having platform architectural biases (suspected or real!), or casting your platform in poor light.

In general free software slows ever-present market pressure to support only a single platform, or a very narrow set of platforms.

Free software is an inclusionary style for platforms, versus the more prevalent exclusionary style (i.e. support for only popular platforms), traditionally adopted by software vendors. The result is: free software supports choice and proprietary systems can effectively limit choice. A platform vendor, with a well integrated stack of free software can field a competitive solution, even in a niche market.

The result is: free software supports choice and proprietary systems can effectively limit choice

Revision management and product evolution

Worried about vendor viability?

You don’t need to negotiate putting code in escrow as insurance for critical projects. You have the source code now, and forever. Normally you can’t inspect the escrowed code ahead of time. When the time comes, and you have a need to gain access to the source, it won’t be the time to find out how much effort is needed to support it.

Worried about new releases?

You can monitor the development activities in the beta code base, bug lists, etc. and measure progress for yourself. No more blind acceptance of a vendor’s optimistic delivery dates, that are unlikely to be met. You can even help to pull in schedules, with people or funding.

Want to be a beta tester?

Everyone can beta test the next release. It’s an open process, not restricted to a privileged few. You can verify its stability and features, get a jump on using it, and then plan accordingly.

It’s then released for development, or production use, when the free software development team feels it’s ready. It’s not just released so that quarterly revenue targets can be met for management. There’s less chance of you helping a vendor debug their product when it’s not really ready for prime time.

Enhancements

Need a feature?

You don’t have to wait for the vendor to add features you need. If it is urgent, you can do it yourself. Be warned though you should offer the feature back to the community. You should avoid supporting a specialized version of the code, if you can. Leverage the community.

Test a feature

When you add features and submit them back to the community, a lot of people you don’t know, and don’t have to pay (but who are very smart) will help you improve it.

Community members can’t make bad ideas become good ideas, but they can turn good ideas into great ideas

They can’t make bad ideas become good ideas, but they can turn good ideas into great ideas.

You can buy influence!

If it’s really important, you can also participate in the overall development process. You can influence schedules and priorities by contributing. It’s the gift that keeps on giving, as others pick up supporting the project where you leave off.

If it’s not that important to add new features, you can still enjoy the benefits. Nobody makes you contribute: use it “as is”.