Open Standards vs. Open Source, Part 3: Open Source Software

Print Friendly

Podcast of this blog entry

pdf version I want to jump to the punch line even before I make some definitions: open source software is something that you need to consider very seriously.

This is true whether you are a user of software, a creator of software, a software distributor, a software integrator, a software solutions provider, or a venture capitalist. There is a difference, though, between seriously considering something and eventually doing something with it. Nevertheless, if you don�t educate yourself about the possible role of open source in your business, organization, or government, you might be leaving yourself open to missed opportunities and cost savings, as well as increased competitive pressures.

You need to be able to accurately assess what is the right balance of proprietary and open source software that will optimize the results you are trying to achieve. In this part I�m going to look at open source software and some of the factors that you need to examine in your serious consideration of its use.

Fundamentally (and informally), �open source software� is software where you can see, re-use, and redistribute all or part of the source code, plus some fine print. There are two fundamental concepts here: what do I mean by �source code� and just what is this �fine print�? If you are a software developer, you know all about the former, and if you are an intellectual property attorney, the second is your specialty. For those of you who are one or the other or neither, I�ll discuss both.

�Proprietary software� is usually made available in a form that will run on your computer, but you are not given the original material from which it was created. You cannot freely incorporate proprietary software in your own products, though you may be able to obtain some sort of fee-based license to let you do this. The basic idea here is that proprietary software contains intellectual property that was created by the software provider and that is not shared because it offers competitive advantage.

Licensing proprietary software to users for a fee is a long standing business model in the software industry. Licensing is not the only way revenue can be created, and it is often supplemented with subscription, maintenance, and support charges.

There are precise definitions of what is and is not open source software, and I think the Open Source Initiative should be your primary source of this information. I�m going to adopt a more informal approach to give you enough of an idea of what people talk about when they discuss open source. That said, when you develop your open source strategy and management plan, you need to be quite careful of the details, particularly the legal ones concerning licenses. Of course, if you are using proprietary, commercial software I hope you are looking at those licenses with a great deal of care as well.

There are people who think all software should be open source and there are others who think that no software should be made available that way. This has at times caused political, if not almost ideological, arguments about the nature of open source and its relationship to economic systems. I am not exactly neutral, but neither am I at either extreme. The ultimate choice of what to use belongs to the customer and consumer.

If open source drives innovation and increases competition, that�s a good thing. If it allows businesses to be more creative in their business models as I described in the last section, then that is a positive effect. If proprietary software provides the functionality, scalability, security, and performance that you need, then it may very well be what you should use today. (This is with the caveat that proprietary software should not lock you into its use by avoiding the use of real open standards.)

The software industry is changing rapidly, so make sure you re-evaluate your decisions at least yearly, if not every six months. Open source projects may get better in that time, but so too may proprietary products, possibly spurred on by open source competition.

It is likely that your world will increasingly be a hybrid mix of both open source and proprietary software. You may not even know this is happening. For example, approximately 70% of all websites use the open source Apache web server. When you browse the web, even if you are using a proprietary operating system and browser, you are still employing open source to carry out your tasks.

�Code� is the set of instructions that makes computer hardware do things. Hardware has low level code built right into the circuitry. There are also special chips that can be altered dynamically to have different instructions: this type of code is called �firmware.�

�Software� is a general term that includes firmware, but most frequently means the very large class of sets of instructions that make general purpose chips made by IBM, Intel, AMD, Sun Microsystems, and others do a wide range of things. Using the same hardware, I can create and run software like video games, operating systems such as Linux or Windows, accounting software, word processors, web browsers, email programs like Lotus Notes, banking systems, travel reservation systems, databases, and many others.

Software can run on top of other software, such as a spreadsheet running on the OS X operating system. A macro in a spreadsheet is also an example of software, though it is relatively small compared to the spreadsheet software itself. Informally, we call software that runs on operating systems �applications.�

The term �program� is used generally and vaguely to refer to any software that accomplishes a particular task. People who create software go by many titles. Here are a few: programmer, software developer, software engineer, application developer, and coder.

Just as I am using a text editor to create and then save this document to my hard disk so that you and others can read it later, I can use a programmer�s editor to create the code for a particular piece of software and then save that on disk. This document is translated by your eyes (if you reading it) or your ears (if you are listening to it), and then your brain into something meaningful (I hope). In the same way, there are special programs that translate high level code into the low level form that some particular kind of hardware understands.

My words in the text are the source for any direct understanding you may get from this document. The high level code is the source for the low level instructions that the hardware understands, hence the phrase �source code.�

Just as it would have been possible to write this article in French, German, Russian, Japanese or some other language and still have it understood by a speaker of those languages, there are different languages in which a software developer can create source code. In fact, the original source code for an application can be a collection of parts done in several languages.

To fix ideas, here are some of the names of some software programming languages: Assembler, FORTRAN, BASIC, COBOL, Lisp, APL, C, SmallTalk, C++, Java, Perl, C#, Python, JavaScript, and PHP. The languages tend to get newer as you move from the beginning of the list to the end. Some of these languages, for example Lisp and PHP, are very different, yet they nevertheless all are ultimately translated to instructions that are run on hardware.

Some languages are better than others for helping you accomplish certain tasks. PHP is better for developing websites than COBOL, but COBOL is better for developing traditional transactional enterprise applications like high performance banking systems.

I don�t think there will ever be a time when only one programming language is used by everyone for every kind of task. There are engineering reasons that determine why programming languages are created and used. There are also computer industry political and competitive motivations, such as the developer of a particular operating system who creates a language that primarily runs on that operating system and makes it difficult to move applications to other platforms.

As I mentioned above, an application may be created by combining several different parts. Why might I do this when I am developing software? One reason has to do with design: if I can factor a big application into smaller parts, or modules, and they have well defined ways in which they talk to each other, then it is easier to understand, create and fix the smaller sections, while having the whole fit together like a jigsaw puzzle.

Modules can also be written by different people, sometimes living in different parts of the world or working in another part of an organization. For example, if I am an expert in writing code that draws and manipulates photographs on a computer screen, then it makes the most sense for me to focus on implementing modules that need that sort of function, rather than have me write code for something completely different, like databases.

Another good reason for using this modular kind of design is that I can re-use the pieces in different projects. The more I can re-use, the faster I can develop software. If I know that the individual modules were written and maintained by experts, I have greater confidence that the software I put together will be higher quality and that I am efficiently leveraging the work of others.

So software applications can be broken down into components called modules and they can also use collections of special routines that are stored in what are called libraries. For example, I might have a library that does fancy mathematical calculations. If the modules and libraries are available as open source, then many people can use them freely. They can also look at and possible improve the code and then share that.

This means that a community can develop around the code to create, maintain, and improve it. This benefits everyone who might be able to take advantage of the code in their own projects.

One important place to do this sort of thing is where standards need to be implemented. If I am creating a word processor, then it makes sense to have a module that knows how to read and write the OASIS OpenDocument Format (ODF), and it is the only part of the program that does this. The rest of the application can use whatever form makes sense internally to store the information from the document, but when it needs to saved to or read from disk, then that one module will be used.

If I am writing an extension for a web browser that needs to read and then display an ODF document, I can re-use that module if I have access to it and have permission to use it. If there is a problem in the module or the standard gets updated, I can change the module if I have access to the source code. If I have access to the source code, I can read it and become a better software developer by looking at how certain tasks are handled.

If I don�t have access to the module or its source code, I have to write new code to process the ODF. With luck, I�ll do it perfectly … eventually, though it seems a waste of effort if someone has done it before.

If everyone uses the same software module to implement a standard and it is high quality software, then more people can develop applications faster that use the standard correctly. In this way, the easy availability of software can accelerate the adoption of a standard, with all the resultant goodness of systems that can speak to each other.

If support for a standard comes with an operating system or a software development environment, then many of the things I just described may be true. However, if the standards support is proprietary you probably will not have access to the source code and you may not be able to use that standard as easily on other platforms, such as different operating systems.

This trade-off may be acceptable, but you should accept it, if you do, after careful consideration. You will need to depend on the vendor for updates and fixes to the software at the pace he or she decides to provide it. You also need to be careful that the vendor supports the standard correctly and that there are not hidden security problems or special vendor extensions.

This can be hard to tell if you don�t have the source code but, again, might be acceptable. You get to make the choice. If the vendor supports multiple operating systems and platforms, you are less likely to have the sorts of problems described.

If a vendor has a history of and reputation for delivering proprietary software that provides significant value and high quality, secure products with good support, this may outweigh the advantages, to you, of having the source code open. If, however, the way the vendor develops, licenses, and supports his or her software will lead you to being locked into his or her world with limited future choices and flexibility, then you should carefully consider the possible advantages of an open source solution.

In a somewhat round-about way, I�ve described software development and pointed out some situations where it would be advantageous to have access to the source code. There is more to it than just seeing the code or having it shared in some limited way by a vendor.

Open source fundamentally means that you can benefit from the work of others and, in turn, others get to benefit and extend your work. In this way, the software development community can make progress by working and innovating in a collaborative way. It�s the power of this community working in an open, transparent way that helps make this model of software development work.

Why would you not want to make the source code for your software open and available? Here are some possible reasons:

  • Your software contains code from other people, and you don�t have permission to give their property away.
  • You are getting strategic advantage, differentiation, and revenue from your software and you don�t want to give that up.
  • Your customers are content with the current situation and business is good.
  • You are operating in a niche market and there is no pressure to open source.
  • There is no community of developers outside your organization who will help you further develop the code.
  • There�s nothing you need from developers outside your organization and you don�t want to share what you�ve spent your own resources to develop.
  • The less others know about your code, the easier it will be to keep them from moving to competitive products.
  • You�re embarrassed by the poor quality of your code (don�t laugh, it happens).
  • You fundamentally do not believe that sharing source code is the right thing to do with intellectual property because it might cause damage to the existing business model of fee-based software licensing.

Here are some reasons why you might want to make the code available as open source:

  • The code implements a standard that you want to be widely adopted.
  • You�ve used other open source code and you want to give something back to the community.
  • There is no special business advantage to keeping the code private and you want to make it available for others to use and learn from it.
  • Your code contains some real innovations that you want to be widely used.
  • You are very proud of your code and you want others to see and use your work, and then think you are a superb programmer.
  • Your business model allows you to generate revenue in ways other than charging people who want to use your software.
  • One of your competitors has a business model that does not allow him or her to generate revenue in ways other than charging people who want to use his or her software.
  • The code was developed while you were working under a government grant, and you feel that you owe it to people to make it publicly available.
  • By making your code available, it will allow others to innovate on top of the foundation you are providing. That is, you think that innovation will happen faster if others don�t have to �reinvent the wheel.�
  • You believe that all source code should be freely available in the same way that academic results have been shared for centuries.

Now, the fine print.

A particular open source project makes its code available under a specific legal license and this lays out the rights, restrictions, and responsibilities you have when you use the code. There are many licenses and the Open Source Initiative lists many of them. They are not all compatible with each other and you cannot and must not necessarily mix code covered under one license with code covered under another license.

The most widely used license is the GNU General Public License (GPL). While it is hard to quantify, it appears likely that approximately 70% of all open source projects use the GPL. Code that uses the GPL is referred to as �free software.�

By its nature, the GPL makes new code that incorporates older GPLed code also use the GPL. That is, the GPL is somewhat self-propagating as code that uses it is picked up and re-used elsewhere. This is exactly as the authors intended.

The GNU/Linux operating systems use the GPL. You cannot charge others for a license to use GPLed software and you must make your source code available.

Another commonly used license is from the Apache Software Foundation. This is an open source license that does allow direct use of the source code within commercial products. Unlike the GPL, the Apache License allows �defensive termination�: if you sue someone because you claim that the software infringes on one of your patents, then you lose the right to freely use the patents of others that are implemented in the software.

In other words, you stop having the right to use the software if you are trying to stop others from using it. Much of the open source software that implements the standards of the World Wide Web is covered under the Apache license.

There are many other licenses but a handful of them cover well more than 90% of all free and open source software. I illustrated a few of the sorts of things that licenses can include but there are others. If you are planning to open source your code, study the licenses carefully. If you are planning to use open source code in a product, also study the licenses carefully and you should probably speak with an intellectual property attorney.

With care and some flexibility on your part, you can very likely accomplish what you wish to do. Treat license considerations very seriously.

In the first section I spoke about standards, in the second I discussed software and business models, and in this section I dove into what open source is in a way that I hope makes clear some of the differences from the traditional, proprietary development methods. I hope that I�ve justified to you the assertion from the very first sentence, that you must seriously consider open source software.

I want to emphasize that we are now and will continue to live in a hybrid open/proprietary world. I also fundamentally believe that whether we are talking about standards or software, we are advancing towards increasing openness.

We are seeking greater transparency into what our software does, how it works, and how it interoperates with software elsewhere in our own organization as well as those of customers, partners, and suppliers. We are looking to leverage the community to build a strong foundation of software and standards on top of which we can innovate.

Finally, we want greater certainty that vendors will not be building things into software that benefit themselves at our expense, particularly if it limits our future choices of what applications we use to access the data that we ourselves created.

In the next and final part I�ll tie all these threads together and talk about how and why Service Oriented Architecture, or SOA, is accelerating this movement towards openness.

Comments are closed