Open Standards vs. Open Source, Part 2: Software

Print Friendly

Podcast of this blog entry

pdf version In Part 1 of this discussion of open standards and open source, I focused on what a standard is and what it means for it to be open. I compared a standard to a blueprint and said that we separate the ideas of “a standard which may be implemented” and “something that is an implementation of a standard.” Open source is a particular way of implementing and distributing software, enabled by legal language that gives a range of permissions for what people may do with it.

Just as we saw in the first part that there are a number of factors that can determine the relative openness of a standard, so too are there conditions that allow, encourage, or even demand behaviors from people who use or further develop open source software. In this part I�m going to look at traditional commercial software and then in Part 3 contrast that with open source.

I�m going to assume you have an intuitive sense of what software is, though we’ll return to that in a few moments since it is important for understanding what one does with open source software. Software is what makes the physical hardware in a computer do its magic.

That is, software might be a web browser, an online customer sales tool, a video game, a database that supports your local bank, the reservation system for an airline, the invisible commands that respond to your actions in your handheld MP3 player, or even what controls how your automobile changes its mix of gasoline and air as you start to drive up a hill. These are just examples, and I�m sure you can think of many more.

You can also probably think of several different �titles� of software that are in the same category, such as Halo, Doom, and Syberia in the video game category, and Microsoft Word, Corel WordPerfect, and Lotus WordPro in the word processor category. These are all examples of commercial software: you pay money and you get a legal license to play the game or write a novel by using the software.

The license gives you certain rights but also places certain restrictions on what you can do. The features and value of the software, the cost, and the rights you obtain determine if you pay for the license. Similarly, if you don�t find the restrictions too onerous or unreasonable, then you might be inclined to agree to get and use the software.

Depending on how you look at it, some of the rights might be seen as restrictions. For example, if the license says �you have the right to use this software on one and only one computer,� then you are restricted to not putting the software on two or more computers. From the perspective of the company that wrote and licensed you the software, this is probably very reasonable because the company (the �developer�) wants to be remunerated for its efforts and its costs for creating the software.

The solution to running the software on multiple computers is easy: you make some sort of deal by paying more. Minimally, if you paid $50 for one copy then you might expect to pay $100 for two copies, $150 for three, and so on. You might be able to do better than that, particularly if you are dealing directly with the software provider and you need a lot of copies. Tell them you need 1000 copies and see what they offer you!

Ultimately, the provider of the software wants to get paid and even make a profit, and probably the more the better as far as he or she is concerned. It can be complicated to figure out how much to charge, but sometimes the market will decide for you.

For example, my son William has a handheld video game machine and games for that never cost more than $40. A vendor could try to charge more for a game he or she creates for the machine, but if potential customers think it is too much, then they won�t buy it and the vendor won�t recoup his or her development costs.

If the vendor charges too little and the game becomes very popular then he or she might be �leaving money on the table.� That is, the vendor might have been able to generate greater revenue and profit by charging as much as the market would bear.

Sometimes charging less for a video game can cause more people to buy it. If there is an aftermarket for things like game hint books, stuffed animals of the game characters, and a movie deal, then the software provider might significantly lower the game price to get as many people as possible playing the game. The real profit might come from the aftermarket products.

Might the price ever go to zero? In theory yes, but it rarely happens when the game is new. Nevertheless, it is an interesting idea to give a game away if you can generate a tremendous amount of money in other ways.

This sort of thing is not entirely unheard of: my family has bought boxes of cereal that had free DVDs in them and the local fast food restaurant has given away DVDs with certain meals for children. In this last example, if the DVD promotion is successful enough that it significantly drives up the sales of food, then the restaurant chain might end up paying quite a bit of money to the distributor of the film or films.

Business models around software therefore are more sophisticated then simply saying �I will get all my revenue from what I charge to license my software.� The software developer is interested in the total revenue, remember, even if not all of it or even the majority of it comes from licensing.

Thinking beyond the video game category, we can see other ways to make money in the software business. One is support. What happens when the user of the software has a problem? He or she might search the Web for an answer or, failing to find a solution, might call the software provider for assistance.

Is this assistance free? It depends. Sometimes there is free support for the first thirty or more days after you bought and registered the software. Another option is to give the user one or two free calls and then charge after that on a per phone call/time taken to resolve the issue basis. Yet another option is to charge a fixed fee for a year�s worth of support, though there may be limitation on how many times you can call.

It�s not uncommon to have tiers of support levels, from something fairly minimal to something which is comprehensive. The more you get or think you are going to need, the more you pay.

There can be significant money in providing support. In fact, if the support just concerns how to use the software, there can be companies with no relationship to the original software provider that provide support packages. In this way, a particular piece of software starts to create what might be termed an �industry� that extends beyond the original developer.

What happens if there is fundamentally something wrong with the way the software operates, a �bug�? Someone with access to the original source code must go in and figure out what the problem is, find a solution, and then distribute either a new version of the software or something that fixes the specific area that is causing the problem.

If you do not have the source code from which the software was created you can: 1) wait until the original vendor decides to fix it, which may very well be the best solution for non-critical items, 2) find a work-around, that is, another way of doing what you wanted, or 3) switch to an entirely different application that does not have the problem. There can be many kinds of problems, but security and data corruption ones are especially serious.

If you had access to the source code for the software, could you fix it yourself? Maybe, or you might be able to find or pay someone to do it for you. Are you concerned that the provider of your software might not be in business forever and so you want the extra insurance of having the source code in case you need it eventually? Maybe.

You might sleep better at night, as they say, by having the source code but you also might sleep just as well if you had a vendor you trusted and knew was going to be around for a long time. You will need to decide for yourself. You should make this decision from practical business considerations, not political or ideological reasons. We�ll return to this in Part 3.

Another area where a software provider might be able to generate revenue is in services. If I decide to buy new accounting software, how do I get the information from my old system to the new one? How do I connect the new software to the customer relationship management (CRM) software that my sales team uses?

These tasks might be easy to accomplish but, then again, they might not be. You might have the expertise yourself or on your staff to do this work but, then again, you might not. To whom do you turn for help in making your systems work together? It�s possible that the provider of your new software will do the upgrade and integration work for you, but they may not do it for free. There may be other service providers who can do the job better or at a better price.

Perhaps there was a company that put together the various hardware, software, and networking components on which you run your organization. It might be a good idea to pay them to do the transition to the new software. Again, there may be someone who provides value to you around the software who is not the original developer.

The more successful and widely used the software is in the market, the more service providers there will be. This can be a bit of a �chicken and egg� problem because the software might not become successful until there are enough service providers to help customers get the most value from it. This is one reason why software vendors like to have many business partners.

The partners may provide software rather than services. It�s not uncommon for a partner to specialize software for use in a particular industry. For example, the partner may work in the legal industry and provide special templates that make it easier to produce a broad range of legal documents with consistent formatting. They might provide document management software so that the attorneys can find and retrieve documents.

In this case again, the original word processing software enabled others to develop an aftermarket. The aftermarket can further increase sales of the software, setting up a �virtuous cycle� in which everyone makes money and the software might achieve commanding market share.

I went through this to show you how the creation, distribution, and use of software can create economic value and revenue that extends beyond the initial price that is charged for a license. Anyone who only looks at the license cost is not thinking broadly enough about the big picture.

Software quality is also important. If a customer support application crashes often and loses important data, then it probably isn�t too important that it is less expensive than a more stable product. Conversely, higher quality software that costs less than the competition deserves to gain significant market share. In particular, software with security and privacy problems can sometimes not be worth any price.

Software features can affect price, though it is not the total number of features that is important. Rather, are the features that people really need well implemented? Are they easy to use? If I only use 20% of the features of a piece of software and I can find another application that only implements the features I need and costs less money, should I go with that?

Before I leave this discussion about commercial software, I want to talk again about standards. Standards make things work together. In an example above, I talked about integrating a new accounting system with my sales� team CRM software. How exactly do you do that?

If both pieces of software come from the same vendor, it might have some special language and protocols that link the two together. The vendor will probably claim that this makes everything work more efficiently. This is dangerous.

Proprietary schemes for connecting software make it very difficult to substitute software made by one vendor with software made by another. This is exactly what the vendor that creates the accounting and the CRM software wants. This gives control of your system to the vendor and limits your choices. Again, this is what the vendor in question wants.

This situation is called �lock-in� and, as I said, is dangerous. You want the ability to choose the best software for your organization, no matter what the cost or who the provider is. These proprietary schemes can become the de facto standards I discussed in Part 1.

When the industry agrees to common ways of having software from different providers interact, then you the user, the customer, the consumer, the citizen wins. To repeat myself for emphasis, open standards allow software made by different people to work together and gives you choice and control.

One of the ways in which software works together is by sharing information. It should be a hallmark of modern software that the way this information is represented should not be proprietary. You want the ability to use any software that you wish to interact with your own information.

The price of the software is irrelevant in this regard. More expensive software should not be accorded more leeway in using proprietary ways to represent your information. Similarly, software with greater market share should not force more restrictions on who and what can use your data.

Through this discussion I�ve highlighted several important aspects of software, and have focused on examples of software for which you pay for a license:

  1. The license fee can be larger or smaller.
  2. The license fee can affect market share.
  3. Market share might be increased by a lower license fee.
  4. Support is one way of generating revenue from software, and it is not limited to the original developers.
  5. Service delivery is another way of making money in the software business and neither is it limited to the original developers.
  6. Open standards are important for allowing software made by different people to work together.
  7. The price of software is irrelevant when thinking about whether open standards should be used: they should. End of story.

What would happen if the price of the software was zero (in any currency)? What if you had access to the source code and could make any changes you wished? What if you could build new software on top of software created by others without paying them?

Is this anarchy? Will capitalism survive? How will we make any money?

We�ll look at these issues in Part 3.

Comments are closed