Section 1.10.  The Different Roots of Commercial Software

1.10. The Different Roots of Commercial Software Commercial software comes into existence in a completely different way. At the core of the creative process for commercial software is a vision that many people will pay for the software being created. For open source software, the intended audience and the developer are usually the same. So there is no mystery about what the audience wants. The requirements process consists of developers deciding among themselves what they want the software to do. Commercial software companies must somehow determine what the intended customers want. This introduces a large amount of risk into the process, because determining requirements means making lots of assumptions about whom the audience is. The economics of commercial software resemble those of a health club. Customers pay to join the club, because they can get access to a much better facility than if they built it themselves. But the club has to have the exercise machines the customers want. In commercial software, costs are shared across all customers and the company must create software that is powerful and configurable enough to solve business problems in all sorts of different environments. Figuring out the needs of the market is a key skill for a commercial software company, and many people are involved in the process. Investors in the company, or the product marketing department, might conduct research to understand what customers want. Prototypes might be built and put in front of the target audience. The problem for most commercial software companies is that it is fiendishly difficult to tell if they are getting it right. The ultimate test is if the software sells, and the sales staff frequently plays a key role in requirements gathering. But even if they get the first version right, the same issues of what the customers want must be revisited with every new version. 1.10.1. The Commercial Software Life Cycle What generally happens with a successful software company is that the first version of the product is released, a few initial sales are made, and these customers start providing more and more information about what they like about the product. 1.10.1.1 Requirements gathering and the product roadmap At most software companies the product management department keeps the list of potential features to be added to the product and crafts the definition of what each version will include. The product marketing department focuses on understanding what customers need (inbound requirements gathering) and then sending the message about why the product is of value to customers (outbound marketing). The challenge in this process is that 10 or 20 segments of customers and potential customers might be providing information. The potential feature list is gathered from the developers, sales staff, product management, and product marketing. In most cases, even before the first release, the feature list contains years of work and hundreds of potential features. Each customer has his own opinion about what is most important. The process of deciding what to do next involves several factors, among them balancing the features desired by the customers currently buying the software; adding features that might be attractive to new buyers; adding features that allow integration with other software in the marketplace; and adding features desired by other software companies that are using the software as part of their product or helping sell the software in combination with their product. In performing this balancing act, a company must ensure backward compatibility, which means that new features must not break old ones or force customers to redo work to configure or customize the product. One way companies communicate their decisions to potential customers is through a product roadmap, which shows which features are coming along in the next version and what can be planned for future versions. Notice how different this is from the open source requirements process. In the commercial process a group of peopleengineers, product managers, product marketers, sales staff, senior managersis trying to figure out what another group of peoplecustomers and partnerswant from the software. In the open source process there is only one group, the open source community. The community decides which features to include in each release of an open source project. And the developers decide what each individual feature should do based on their understanding of the need. The odd shape of the commercial software feature set is caused by that attempt to balance the perceived needs of the current and future customer base, requests from important customers, recommendations from the sales staff, and features announced by competing companies. Open source features sometimes have an odd shape, because the competing and conflicting needs of developers are being balanced in a strange compromise. 1.10.1.2 Productization One of the most challenging aspects of creating commercial software is taking a program that provides certain features and functionality, and turning it into a product. Many promising software companies fail, because they underestimate the difficulty and importance of this step. Productization means making software work for the general case and making it as easy as possible to use. For a custom program written by an IT department, it might be fine to have an XML properties file that controls the program. For a commercial product, users will probably expect a simple administrative interface to help set the parameters. For an open source product, installation might mean unzipping the source code, compiling the program, and then figuring out how to fit it into your production or development environment. Commercial products generally have an installation program that does a lot of this automatically. Productization requires a huge amount of work. It can take double or triple the amount of work it took to complete the original features and turn a program into a product. Here is some of the work that takes place during productization: Creating administrative interfaces Writing installation scripts Testing features Testing on different platforms Performance tuning Runtime monitoring through SNMP Creating engineering documentation Creating end-user documentation Developing adapters to other programs, such as reporting software Developing support for different databases and operating systems Creating graphical configuration tools Developing APIs Developing web services It is not crazy to think of an original development team of 5 requiring a productization team of 50 or more with various specialized skills to complete a product. What happens in most start-up software companies is that the original development team becomes the productization team, which causes two problems. First, the engineering team doesn't like the work of productization and is not good at it. Second, it slows down development of later features. Early in a company's life, highly skilled customers oriented toward innovation will do without many aspects of productization as long as the functionality provided by the software is compelling (these people fall into the innovators category of customers we will discuss when we talk about the Open Source Skills and Risk Tolerance model in Chapter 3). This happens because the companies that are most likely to buy new versions of commercial products are composed of innovators and early adopters, and they have the skills to overcome the lack of productization. But if a company does not learn how to productize its software, it is doomed when it comes time to sell to a broader market. 1.10.1.3 Maintenance and support Once a commercial software product has been released, it is supported with patches and bug fixes as needed. It is also supported by a technical support department that answers questions, and perhaps a training and education staff. Support services can be delivered through online resources such as email, or through discussion forums or telephone support. Customers must usually pay between 15% and 25% of the original licensing fee in annual support costs. The presence of a support team to help solve problems is one of the most popular aspects of commercial software. It is also required, because users don't have access to enough information about how the product works to solve problems on their own. But even if all such information were available down to the source code, IT users of software still want support. Later in this book, we will analyze the emerging category of companies that provide support services for open source software. 1.10.1.4 End-of-life When a commercial product goes into end-of-life, it means it will no longer be improved. Bug fixes and support might be provided for a limited period, but after that, commercial software companies will stop fixing bugs and answering questions about the software. End-of-life happens for many reasons. Perhaps the product did not succeed, or it was superseded by a newer product. Companies can afford to support only a few versions of a software product. If Version 4 is just coming out, Version 1 that was released five years ago is no longer as important to customers or to the company. Version 1 might go into end-of-life so that resources can be focused on recent versions. Sometimes, companies put versions into practical end-of-life by raising support and maintenance fees.