Date: Wed, 4 Nov 1998 11:24:23 -0800 From: "David O'Brien" <obrien@NUXI.com> To: freebsd-advocacy@FreeBSD.ORG Subject: (FWD) FWD: the day after make Message-ID: <19981104112423.A20974@nuxi.com>
next in thread | raw e-mail | index | archive | help
This article has some good points we too need to keep in mind on what it takes for an applications shop to port their product to FreeBSD. (warning long....) -- David X-URL: http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-thesource2.html The day after make Some practical consequences to consider when developing the open source way Summary The benefits of open source software are becoming well understood in the high-tech industry: A few of the benefits include better bug testing, quicker development, and happy customers who can improve open source applications on their own. But what are the areas to watch? Why are many ISVs still reluctant to adopt the open source model? Using Linux as his reference point, Software Developer Ian Nandhra discusses some of the areas of concern for ISVs looking to write software for Linux the open source way, including which C library to support, which version of which distribution, and training and quality assurance issues. From the Source is LinuxWorld's Forum for industry insiders who have something to say about important issues. (2,400 words) By Ian Nandhra At the risk of understatement, open source represents a sea-change in the way that intellectual property is viewed and copyright is administered. For once the source code has been released, it is difficult, if not impossible, to reverse the situation. The open source model is extraordinarily successful at getting product developed and tested on a huge array of disparate systems in a host of different languages. Better yet, almost 100% of the development and testing effort is done without much money changing hands. It's a huge development resource, and one that has proved to be extremely beneficial to many organizations. (Open-source software is not necessarily the same as free software, see the [21]glossary below for definitions.) Open source also simplifies support and future maintenance and makes the practice of keeping software in escrow almost obsolete. Since source code is always available, companies can hire their own developers to implement any changes they like. In short, it the perfect situation for the developer, delivering unlimited access to a huge library of royalty-free source code. In competitive markets where one vendor wants to completely dominate, releasing source code to establish one's APIs as the de facto standard makes a lot of sense. This was Netscape's strategy in releasing the Mozilla source code. Furthermore, porting an existing Unix application to the open source Linux OS is generally a breeze. While Linux is still not formally Unix, most Unix applications will at least compile on it. And any defects in these ports are generally easy to identify and repair. But the open source world does present some significant challenges to developers. Take Linux, for example. With Linux, the trick is not deciding whether to port, but rather, deciding which Linux to port to, and how best to maintain that port. Which Linux? Most ISV ports to Linux will target a specific distribution (check out [22]www.linux.org for lists), often without knowing that there are major portability differences among Linux flavors. The most serious concern involves the C libraries -- of which there are two incompatible versions in circulation. This fact, coupled with some other inter-distribution incompatibilities quickly creates multiple source trees for your Linux application, as it tries to conform to the various distributions. Hey, if you love Unix, you should feel right at home here. Split source trees are prime ingredients for future problems. In any case, porting is not just a case of typing make, burning a CD, and throwing it at your customers. The majority of the work, often unseen by the developer, concerns testing, quality assurance (QA), support infrastructure, and training. The large customers (be honest, everyone wants lots and lots of large customers; we're talking about world domination, after all) will invest in internal support and lots of internal training. None of the participants welcome change. Change costs money. Eliminate the negative The most fundamental difference among the various Linux distributions concerns lib -- the C library. There are two flavors in use, libc5 and glibc2 (also known as libc6). So which lib do we port with? Simple. If we want compatibility with the latest (but not necessarily best) version of Linux, port with glibc2 (a.k.a. libc6). If you want compatibility with the overwhelming majority of existing Linux installations, go with libc5. Distributions installing glibc2 also install libc5, so you should have no problems. There are two basic reasons not to port to glibc2. * Maturity. Glibc2 is still being developed, and ISV reviews of its use have been mixed. Glibc2 is also closely linked to kernel releases and has not proved stable enough to be universally adopted. Most people seem content to wait until things mature. * Compatibility. Porting to glibc2 excludes your application from a very large installed user base of libc5 systems. Though some argue that by providing source code to the application allows the binary to be recompiled when the libraries change is, in fact, impractical. A potential customer, say a large bank, will be both unwilling and unable to recompile and re-install the code on several hundred workstations. Even if the bank were to recompile, the question of testing and QA remains unaddressed -- except for the fact that the bank is now using an untested product. You don't need an MBA to know that this is not a winning sales pitch. Future proofing The problem of keeping your application maintainable is addressed by every ISV port. The port has to meet current and future customer requirements, and must also be flexible enough to interface with existing legacy systems. Proving the source code allows changes to be made to the application to meet changes in a given installation or site. There is no shortage of help on the Internet where almost any programming question will lead to a myriad of answers. But what of applications ported to an open source platform (say Linux) and released without the source code? And what if the source code cannot be recompiled on-site? Let's say a product is ported to Linux and becomes popular, the installed base rising to 5,000 systems spread over, say, 1,500 sites. The provision of source code could easily result in several hundred individual source trees springing up over a number of different organizations and sites. Those of us who can remember releasing interpreted BASIC applications will remember the problems of the customers "fixing" their systems by changing the source code. Linux deployment is too new to determine the nature or impact of this problem, but there are already Linux applications statically linking to libraries to avoid the inconsistencies and problems resulting from the rapid Linux upgrade cycles. There is also a growing market for old Linux distributions, loosely termed "legacy Linux." People continue to buy Red Hat 4.1, old SuSE, and who knows what else. Why? They do it because they either don't want to or cannot upgrade. This "if it ain't broke don't fix it" thinking is backed by the costs of upgrading large-scale deployments. Binary only? No Way! There is no such thing as a free lunch. Anyone porting to open source will quickly discover that there is a huge groundswell of opinion that really frowns on so-called closed software releases. While there is support for organizations distributing such products, there is always a strong desire to see an open source (and free) equivalent. There is also constant downward price pressure on any product ported to Linux. For example, it is possible to get a complete Red Hat distribution, with manual, for less than $10. The price originally started at $50. Releasing the source code reveals all your intellectual property to the world at large, most notably to your competition (who will obviously want to profit from it). Releasing an open source distribution will result in a quicker development-to-market cycle -- that can often result in a competitive advantage to which competitors may have difficulty responding. One of the consequences of opening up your source code is that one source version will quickly prevail over the others -- a form of software Darwinism. This, in turn, will mean that there is one version of the product (say for example, a Web browser) which will make it very difficult for commercial competition. The open source business model assumes companies will make money from support and other related activities. Paradoxically, the chances of this are actually enhanced by the difficulty of finding qualified developers to make the required changes to the source code that the frantic development pace fosters. Given the pace at which open source technology changes, it could be argued that the entire business model is future-proofing jobs for the developers writing the code. Think this is wrong? Consider how many operating system kernel specialists are available. Or how many people have experience with compiler internals. Regardless of anything else, the first company to get a good source code release to market will almost certainly win. The penalty for getting it wrong is severe, since the intellectual property has been put into the public domain for anyone (that means your competition) to use. This is a paramount consideration for any organization considering releasing its source code under the GPL or open source licenses. Don't tell anyone, but... A lesser mentioned side-effect concerns the possibility that the source code can be taken and used in binary-only releases in ways that would be almost impossible to detect. The availability of such a vast range of free source code makes a very tempting target for organizations wanting to get product to market. This formerly taboo subject is just starting to be acknowledged as the benefits of a large, free, Internet developer resource is recognized and exploited. It is perfectly possible for anyone to build a product from open source code, but release it in a binary-only form. Any organization doing this would have an immediate commercial advantage over its competition -- the potential development savings are enormous and dramatically cuts the time to market. Update chaos For better or worse, Unix and Windows versions change slowly, allowing ISVs time for the four re's: react, recode, retest, and redeploy. It also allows the user community time to re-train as necessary. It is this stability that underpins the ISV, VAR, and enterprise markets. The constant update cycles that fuel the Linux industry make things difficult for enterprise deployment. In the same way that larger installations will be reluctant to constantly keep pace with the "latest kernel," it is equally unreasonable to make the ISV community do the same. Development is a small part of the life cycle of a software product. The real costs are incurred after deployment, when costs of legacy updates and changes make themselves felt. The support and maintenance costs created by the slow, careful update cycles of Unix and Windows are well understood (OK, at least we have experience with them), but calculating support contracts based on a changing number of Linux distributions with a rapidly changing source base is another matter entirely. One can reasonably assume that an HP-UX installation will not change the entire OS several times a year, but with Linux such changes are common. This is usually done under the assumption that all Linux is the same and everything will be OK. Linux resellers who install multiple applications on a Linux system already know that Linux distributions are different and that considerable problems can be encountered finding a distribution that will run a range of applications. Once a successful formula is found (it currently seems to be libc5-based), there is considerable reluctance to change. ISV applications porting to Linux absolutely have to ensure that they are compatible with all current and future flavors of Linux. Source code availability is irrelevant unless the ISV is happy for the open source development community to change the code base, a move that many may regard as a product takeover. This open development model is incredibly good in specific market segments where there is one, or maybe two competing products. Netscape for example, is the most (possibly the only) successful open source browser; competition is unlikely. How many open source alternatives to Oracle or Sybase are likely? When the source code is mind-bogglingly complex, open source releases win. If the code is relatively straightforward (most ISV applications), source code releases (and their products) will quickly merge. Let's just consider QA Better still, ask your QA VPs about their views on the customer base having unrestricted access to the source code. All ports have to come to terms with the customer's ability to change the underlying platform components and/or the source of the ported product. Having broken the entire installation, they will then complain that the product is defective and will require redress of some sort. (Perhaps this is why support contracts are linked so closely with open source business models.) With non-open source operating systems like Windows NT or Solaris, it is unlikely that the customer base will be able to substantially alter the operating system. For ISVs, this stability is important because it means the developer doesn't have to worry about what the customer might or might not have done to break the OS. Source code availability also requires that all the test and QA procedures for the product are released as well. Now let's be honest, how many products have a less-than-perfect test and QA process? It's not just technical issues Porting to Linux and/or open source is not just a case of the technical difficulties of making the product work. That's the easy part. Other considerations are harder to come to terms with. It has been commented many times that once ISVs are convinced there is money to be made in open source, they will come running. There is already great interest in the potential gold-mine of free development and royalty-free source code. But there is more concern about the way in which free source code availability will undermine a product's revenue-earning ability. This is ably demonstrated by the way that a Linux product will typically be priced 60% lower than its Unix or Windows equivalent. The product is identical, the source is (or should be) identical, so why the drastic price reduction? It's a question at the top of the list of unknowns when considering a port to Linux. And one that your customers will not miss. In conclusion, open source is an incredibly effective tool at breaking into specific or new markets and solving tough problems. It is left to the individual ISV to quantify the associated commercial risks against the potential benefits. The technical part is easy. The commercial risks are not widely known nor debated. So talk to some existing Linux ISVs, check out the competition's plans, and have fun with all the free code. Correction: The original version of this article incorrectly referred to the newer version of the C library as glib. The correct name is, in fact, glibc2. Thanks to Paul Iadonisi for pointing this out. [INLINE] Glossary free software: The original concept of releasing the source code with the executable, governed by the GPL license by Richard Stallman and the Free Software Foundation (FSF). Advocating that all software should be "freely available and available for free." The majority of Linux and "Open Source" code is covered by the GPL. Bottom line: The source code and all changes to it will remain in royalty-free use. open source: The main difference between open source and FSF is that open source software can be sold at whatever price the market will bear. Like the GPL, once source is released under the open source license, it remains royalty-free. Open source is widely seen as more business friendly than the FSF model, since you can at least sell your product. The differences (if any) between open source and Free Software are still debated, but at first glance it seems that both models prompt the same fundamental question from ISVs: How do you make money from something you give away? About the author Ian Nandhra Starting with Intel 8008 CPU's, Ian Nandhra has been developing systems for over 22 years. He is the president and co-founder of NC Laboratories Inc., a Stockton, CA-based application development company. NC Laboratories creates software for a variety of operating systems, including Linux. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981104112423.A20974>