Sound advice - blog

We had a good preliminary scoping discussion today at HUMBUG. I caught the end of Pia Waugh's talk, and the linux.conf.au 2006 debreif lead by Clinton Roy. After dinner a few of us clustered around a chalk board at the front of the lecture theatre. A good canvassing of some of the direction issues was had, despite most of it being carried out before Anthony Towns returned from a separate dinner trip.

I was on the chalkboard, and wrote up the Efficent Software Initiative problem statement as follows (excuse my basic inkscape reproduction):

Libre software is often written gratis, however those who write the software still need to live. They need to feed their families. In short, they need a day job. A lucky few are employed to write open source software for specific companies that use it. Many others are weekend soliders.

We are at a stage in the development of the software industry as a whole where it is usually necessary to be a full time software developer in order to be a particularly useful software developer. It takes a number of years of study and practical application to write good software, and we want our free software to be good. For those not employed to work on open source, their day job will likely include closed source software. Now, let's assume we "win". There isn't any appreciable amount of closed software development going on anymore. Do these guys lose their day jobs, or can they be employed to work on open source software in a new and different way? It is the function of the Efficient Software Initiative to build a base of discussion and experimentation to answer that question. We want to give as many people as possible the chance to work full time on free software, which means giving them an income.

The initial diagram became a little more complicated as we tried to model the software industry that supports open source developers today. We started by drawing links to that all-important money bubble. The goal was to describe where the money is coming from, including where a business that employs open source software develpers ultimately gets its money from. A simplified version of the diagram follows:

If free software takes over we lose the ability to charge licence fees to support the developer's day job. I see the support-based business model for software development as weak, also. It may have conflicting goals to that of the production of good quality software with a balanced feature set. Real strength in an open source business model comes from being useful to other industries. That does not necessarily mean outside the world of computers. Google or Yahoo have established business models in the internet search industry, and serving their interests is a way of rooting the money supply available to open source without depending on closed software in the value chain. Other industries and established business models abound, including everything from avionics to resturants. To be productive, an open source industry has to appeal fairly directly to this wide audience. These industries can and should be engaged incrementally and won over with sound business logic.

So if we trace our connections back to the developer, we see two main paths still open for the raising of funds. We could try and get them employed directly by businesses that need software and want their particular interests represented in the development of a project going forwards. Alternatively, we could try and raise money over a wider base from the whole user community. This is a community of individuals and of companies who have an interest and an investment in your project's ongoing success. Your project represents a point at which their interests all overlap. The main things that matter on an encomic level in maintaining the community and successfully drawing contributions from the community are to match your project goals with the community interests and to ensure that individual contributions are returned in spades as a collectively built product.

This is an interesting and important facet to the bean counting motivation for open source in business. Businesses like to deal with the existing software industry. They pay a small fee, and in return they get to make use of the produce from hoards of programmers over several years (if not several decades). Open source makes it possible to do the same thing for business. Even though they contribute only a small amount individually, they each recieve the benefit of the total common contribution. They often don't need to work on a bug that affects them to see it fixed. The effort is often expended by someone else who felt the pain more stronly or immediately. Licences such as the GPL also provide some level of certainty to contributors that what they have collaboratively built won't be taken by any single contributor and turned back into a product that does not benefit them.

The difference between open and closed source approaches to this multiplicative return is that open source is more efficient. It stands to reason that when it is possible to fork a product, there is a lower cost of entry to the business than if you had to rewrite from scratch. For an example, just consider the person-years of effort that have been extended on the GNU Classpath, despite Sun having a perfectly good implementation in their back pocket the whole time. If the barrier to entry is lowered, competition or the potential for it increases. This should lead to a more productive and lower cost industry. The current industry forms monopolies wherever there is a closed file format or undocumented API. An industry remade as open source would see none of that, and the customers should benefit.

Benjamin

This is the first in a series of articles I may or may not get around to writing over the next week or so to clarify some ideas leading into the Efficient Software Initiative. Some of the ground in this article is covered also in Math You Can't Use, who's sixth chapter I read after drafting. I think this article is a little more focused on the core economic issues and has value standing on its own. Note that Math You Can't Use makes use of the terms "goods-oriented" and "labour-oriented". I use the terms "manufacturing industry" and "service industry" for analogous concepts. Disclaimer: I am a software developer, not an economist.

It is incorrect to say that software is just maths, and is therefore not patentable. Physics and engineering are just maths, so our total understanding of our physical environment is just maths. If that were sufficient justification to prohibit patent, all engineering design would be exempt from the system. We must instead look for an econmic justification for prohibition of patent on software, and I think such a justification can be made.

The patent and copyright systems attempt to solve the same base problem. If I invest a certain monetary value of time and skills into a product development it is important I can recoup my costs and ideally can make a profit. Because my initial investment excluded input from other parties, so should the benefits I reap. I deserve a limited time monopoly on what I produce.

The problem with this reasoning is that it essentially applies to a manufacturing industry. A manufacturing industry is one where an initial investment is made before and throughout a development cycle, before a later cycle allows me to recoup my costs and feed my family. Mass-market software has traditionally been a manufacturing industry, however this is changing. The software industry is remaking itself around services.

Services follow a different business model. Instead of having to recoup costs at a later stage of product development, services acquire funding "in-phase". Software developers will remember that the old ideal for software development was the waterfall model. Requirements definition was followed by design, and then by implementation. After implementation comes sale and the recouping of costs. We have been moving away from that model for many years. It patently does not work for most software devlopement. Instead, we began with spiral models and have ended up with agile or extreme methods. These approaches to software development dictate a cyclic model. You plan a little, you implement a little, you test a little, and you deploy a little. An important economic aspect of these models is the potential for in-phase recoup of costs.

The agile approach goes as far as saying that a customer representative is on your development team. They drive this week's development and have enough insight into the development as a whole to help make go/no-go decisions for the project. If funding should stop, that is ok. The customer will have selected their most important features for early implementation and will have discontinued the project only as diminishing returns make continuing uneconomic. Because the funding was in-phase, all costs have been covered for the developers. There is nothing that needs to be recouped after the implementation phase. The roles of customer and investor have merged.

So if software is a service rather than a manufacturing industry, if software development does not have to recoup its costs out of phase, then it stands to reason that patent and traditional copyright do not benefit the industry as a whole. The barrier to entry that both systems create to new entrants (particularly the patent system) is a deliberately anti-competative feature and an anti-productive one. They will have an overall negative economic effect when there is no corresponding productivity increase created by the out of phase recoup of costs. Given the software industry's growing importance to the world's economy, it stands to reason that both systems need to die for software. Software patents should be the first to go.

Patents and copyright do not make sense in a services industry. If I patent the ideas behind a dog-walking industry, customers cannot be benefited. Instead, I will be reducing the quality and scope of services available to them and increasing their costs. I should be putting my energies into running my service efficiently, and outsource that which is not my core competancy. If new ideas will make me more efficient I'll spend the research and development dollars to produce them, but the funding will come from the business I run and not from the sale of these ideas to other dog walkers. The same analogy applies to the software industry. If I patent the ideas behind internet search or behind the playing of video files, I am reducing the quality and scope of services available to computer users. I should focus on providing great search and video services to my users and use those dollars to fund any necessary research. If my service is providing software to make a particular business model more efficient, I should focus on meeting customer demand for efficiency improvements. I should not be trying to sell them a product. When the industry is built around in-phase cost structures the patent system only acts to prevent my competitors from matching my performance in ways that lock them out of the whole industry and provide an overall poorer marketplace for the services themselves. Economically speaking, it is the services that count. It isn't the paltry research industry sector.

Patents are intended for industries where it takes a number of years to develop a product and the costs must be recouped later. This works in drug industries. It may even work in research sectors of the computer industry. If I labour away at creating a new video codec system that greatly improves quality for the same computational and bandwidth requirements as convetional technology, I need a way to recoup my spent youth. If such an incentive is not given, the improvements may not be made. However, I would argue that the bulk of the industry will be services-based. Some segments will be hurt by the transition, but for the most part a greater level of innovation will be recorded rather than a lesser one. Segments based around services will work to fund other segments in order to improve their own services offering. This will occur naturally as required, and will also be in the form of in-phase funding.

The change is already beginning, but at the same time existing players in the sofware market are rallying to try and keep competition out. The efficiency of the software industry will suffer if they succeed, and thus the efficiency of the world economy will also suffer.

Benjamin