Sound advice - blog

As many of you will know, I participated in a telephone interview some weeks back for James Purser's Linux Australia podcast. With his permission, here is a transcript of of that interview. Any errors or inaccuracies are my own. If you would like to refer to the original interview please see James' podcasts page. Questions asked by James are prefixed with "JP". Other text is myself speaking.

The major change that has occured in the project since this podcast is that Efficient Software has dropped the concept of a central clearing house for open source software development funding. We now encourage individual projects to follow an efficient software model by accepting funds directly from users. See the Efficient Software project page for more details about what Efficient Software is, and where it is going.

JP: Ok, getting right into our interview with Benjamin here he is explaining what Efficient Software is:

Well efficient software is a project idea that I have had for a few years but it has developed a lot since the AJ Market came online.

JP: Just before we go on, I'm sorry. For those who are listening who don't know what the AJ Market is, can you tell us what AJ has been doing there?

Anthony Towns is a Debian developer. He has opened up a market on his own website where you can submit money to him and it will drive (theoretically) the development he is doing in that week. So it is a motivating factor for him to get some money in his hands, and is also a way for the community to drive him into particular directions as to how he spends his time. He publicised that on his blog and on planet linux australia, so that spurred things along a bit. So this project is similar, a similar mindset. I would like to iron out some of the reasons why users would contribute and look forward a bit as to where we will be in ten years time or twenty years time when closed source software is possibly a less dominant force in the market.

So at the moment it is very little. It is a mailing list. It is an irc channel. We are in a phase of the project where we are just discussing things. We are talking about what this world will look like twenty years out from now.

JP: Ok, well let us in. What is this kind of world view you have got that is behind Efficient Software?

If we imagine a world where open source software has "won the battle", that it's freedom everywhere and everybody can get at the source code and free software is developed. You have to ask the question: Who is it developed by? We have pretty good answers to that at the moment. We have people who are employed by open source friendly companies. We have people who have a day job and they spend their weekends and free time doing software development for free software projects. They have the motivations and the itches to scratch to contribute. But there is a conflict, a fundamental conflict when you have people who are working part time, especially on software development. They have time and money in conflict. They need to earn money, they need to have a day job in order to have the free time to spend on open source. The idea is broadly that we want to be able to fund people as much as we can and we want to fund them as directly as we can potentially from the community itself. When you take out the closed software world a big segment of the actual day job marketplace disappears for software developers.

JP: Yeah. That would be say 80-90% of the employers of software developers, wouldn't it?

Yeah. So we can look forward and see this potential conflict approaching where open source adoption slows down because nobody is willing to give up their day job. They are afraid of contributing because they may want to keep their jobs. What I'm really looking to is how to solve that conflict between the time you want to be able to spend on open source and the money by aligning those two things. Being able to get a direct funding of the developers.

JP: Cool. So what would you be setting up with Efficient Software? What is the current sort of model you are looking at?

Well, I have a strawman and this is preliminary and this is mostly my thinking. I am eager to take on board comments and consider even radical alternatives to this. What I'm currently laying out is a kind of eBay-style website that essentially becomes a marketplace, a central clearing house for enhancements to open source software. The idea is that customers, or users, however you want to think of them... investors, because investment and contributing they are the same thing in open source really. If the customers will find particular enhancements they want, they will be modelled as bugs in a bugzilla database. They will have a definiate start and conclusion and close out and verification process assocated with them. The idea is that the community (that could include individuals and businesses or whatever interests there are the support that particular project) can contribute money to a pool that will be paid to the project once the bug is verified or once that release cycle is complete. So there is a clear motivation there to contribute, hopefully, to the project. You are going to get your bug fixed at a low cost. You can put in a small amount of money and hopefully other people will put in small amounts of money also, and it will build into a big enough sum to make it appetising to go and fix the bug. Then maybe the developer can still pay their bills that week. There is a motivation as well from the developer's side to go for the biggest paying bugs and to try and meet the market expectations of the software.

JP: Have you considered the other systems that we have currently got for paying open source developers, which is say Redhat's and any of the corporate Linuxes where you pay for support, or Sourceforge's donation system where you can go and actually donate to any of the projects?

I think that is a very interesting sort of case study. If you look at a business that is selling support, one of the interesting things I have found in open source development is that often the support you can get for a fee is not as good as you can get for free. It doesn't have the same kind of wide customer base that a genuine open source project has. In an open source world people contribute not only a bit of code, but they will also contribute a bit of time by helping other people out. The reason they do that is that they get a lot of support in response to that. They can put a small amount of investment in and get a great yeild off of that. Commercial support at the moment is good for making business feel very comfortable about their linux investments. You can buy a Redhat CD and install it on your machine and you have your support for that particular machine, and if you want ten machines you buy ten support agreements. It is very much the closed source software development model in that costs in developing the CD are returned after the CD is produced. They also have the support mechanisms in there which is a useful and still will probably still be an important part of the business, the economy of open source going forwards.

Sourceforge is another interesting one where they have opened it up for donations, and that has happened fairly recently. Over the last twelve months, I think. Any community member can contribute to a particular project that they like. My fundmanental concern whith that is there there is no real economic incentive to do that. There are two reasons I can think of economically to contribute to an open source project through that sort of model. One is that it you think it is on the ropes and you want to keep it ticking along so that the investments you have made already will continue to bear fruit as more people put contributions into that particular product. Also there is a sort of "feel good" factor. You might like the product and want to reward the developers. In that sort of situation it is very difficult to determine exactly how much you should actually put towards the project. It goes back to recouping costs after the development has taken place, and ideally we would like to be able to pay the developer as they develop the code rather than come along several weeks or months later and say "I like what you have done, here is a thousand bucks". I am interested in trying to find an economic basis for that relationship to exist between the customer and the producers of the software.

JP: As you mentioned before you have blogged a fair bit about Efficient Software. Including a discussion you had at HUMBUG at the last meeting. What has the response been like?

It has been very interesting. So far it has been fairly minimal, but at HUMBUG we had really good discussion about basically the prelimiary scoping of the exercise of the whole project. We got to talk through the issues of how you get from some other business model some greengrocer or a certain internet search engine and how you get that money feeding to an open source software developer to pay for their day job. We just started to map out the whole industry and work out where the money is coming from and how we can get as direct a flow of money to the developer and as most efficent flow as we can get that will reward the developer for meeting real customer expectations. We discussed a lot of other issues as well and I blogged about them and you can read that on https://planet.linux.org.au/ or my blog at https://soundadvice.id.au/. We have just gone through some preliminary scoping and we are still in very much a discussion phase about efficient software. What I put forward is a strawman, and it is not really intended to be the final model. I think there are some pros and cons which we should really work through and compare to other businesses in a much more detailed way.

JP: So if this were a software project you would really say you were in the Alpha stage of development?

Yeah, absolutely. It is all new. It is all fresh. I don't know if it will fly. I think there are reasons to believe it will succeed. I think there are economic reasons to think that open source software will always be more efficient and cost-effective than closed source software. Particularly due the forking capability of open source there is a very low barrier to entry. If I want to provide a whole new infrastructure for running the project I can just take your source code and I can run with it. If I am more efficient, if I am better at it than you, then I will be the one who ends up at the end. Most of the time what happens is that projects collapse back because there isn't enough of a customer base to really draw from. That includes time and skills of developers, of people supporting other people who are using the product. Ultimately the Efficient Software goal is just to extend that so that money is another thing that your community can provide in an open source sort of way. As they have an itch they can provide either their time, their skills, or some portion of money. I think as we move to less technical arenas in open source... open source really started in operating systems and tools and things. It has expanded a long way from that. We are getting to things like Gnome which which is really meant for the average desktop user. The average desktop user doesn't necessarily have the time or the skills to really put forward to code development. I think there is an untapped supply of funding for developers who are willing to take on that relationship with that sort of community: A community which is less technical and is more interested in their own way of life and their own day jobs.

JP: Do you see Efficient Software being able to benefit the whole range of projects, from your single man developer to your Apache, Gnome, or Linux kernel?

That's really my picture of where this will go. I think there is a barrier as to where this can penetrate, but the barrier is really about whether the software is mass-market and whether it has has mass-appeal. Those are the same sorts of barriers as open source hits anyway. I think this will most benefit non-technical community bases or less-technical community bases and will probably have a lesser impact on things like the Linux kernel where no desktop user will have a specific bug they will want to address in the Linux kernel, necessarily. There may be some flow through. Say Gnome were taking on this model, and they were acquiring a reasonable funding base from their community which is a more non-technical community they may have a reason to reinvest in the Linux kernel itself. Whether that be reinvesting of developer time and resources, or whether that indeed went upstream as money. As we reach out to less technical fields you will see a more money-oriented open source develoment and as we move to more the tehnical areas then it will be people who have the time and skills and are pushing those time and skills upstream.

Benjamin

This bugzilla comment came across my desk this morning:

If there are any developers out there interested in implementing this functionality (to be contributed back to Mozilla, if it will be accepted) under contract, please contact me off-bug, as my company is interested in sponsoring this work.

The comment applies to a mozilla enhancement request for SRV record support. SRV records are part of the DNS system, and would allow one level of server load balancing to be performed by client machines on the internet of today. Unfortunately, HTTP is a protocol that has not wholeheartedly embraced the approach as yet. What I think is interesting, however, is that there are customers who find bugs and want to throw money at them.

The extent to which this is true will be a major factor in the success of Efficient Software. This particular individual would like to develop a 1:1 releationship with a developer who can do the work and submit it back to the project codebase. I wonder how open they would be to sharing the burden and rewards.

This is the kind of bug that seems likely to attract most intrest for the Efficient Software initiative. It has gone a long time without a resolution. There is a subset of the community with strong views about whether or not it should be fixed. There seems to be some general consensus that it should be fixed, but for the project team for whatever reason it is currently not a priority.

It is unclear whether putting money into the equation would make this bug a priority for the core team, or whether they would prefer to stick to more release-critical objectives. There may be a class of developer who is more occasional that could take on the unit of work and may have an improved incentive if money were supplied. That is how I see the initiative making its initial impact: By working at the periphery of projects. I don't see the project being a good selector of which bugs should recieve funds because, after all, if the cashed up core developers thought it was release critical they would already be working on it. No, it is the user base who should supply the funds and determine which bugs they should be directed to.

There are important issues of trust in any financial transaction. I think that an efficient approach can adress these issues. The individual who commented on the SRV record bug is willing to contract someone to do the work, but whom? How do they know whether the contractor can be trusted or not? The investor needs confidence that their funds will not be exhausted if they are supplied towards work that is not completed by the original contractor. Efficient software does this by not paying out the responsible party (the developer or the project) until the bug is actually resolved. Likewise, the contractor must know their money is secure. Efficient Software achieves this by requiring investment is supplied up-front into effectively an escrow account while the work is done.

The biggest risk for an investor is that they will put their money towards a bug that is never resolved, despite the incentive they provide. A project may fork if funds are left sitting in the account. The investor's priorities may change. They may want that money put to a more productive use. I don't know of any way to mitigate that risk except to supply more and more incentive, or to first find a likely candidate to perform the implementation before actually putting funds into escrow. Perhaps the solution is to allow investors to withdraw funds assigned to a bug up until the bug is commenced. Once work is started, the money cannot be withdrawn. If the developer fails to deliver a resolution they may return the bug to an uncommenced state and investors can again withdraw funds to put to a more productive use.

The fact that the efficient software approach is an emergent phenomenon gives me increased confidence that it can be developed into workable process. In time, it may even become an important process to the open source software development world. Do you have comments or suggestions regarding an efficient approach to software? Blog, or join us on our mailing list.

Benjamin

Bounties have been traditionally seen in open source as a way of brining new blood into a project, or increasing the pool of developer resources available to open source. Offering money for the production of a particular feature is intended to inspire people not involved with the project to come in, do a piece of work, then go back to their day to day lives. The existing developers may be too overworked to implement the feature themselves due to preexisting commitments. The item of work may even be designed to cross project boundaries and inspire cooperation at a level that did not exist before the bounty's effect was felt.

There are seveeral problems with this view of a bounty system, but perhaps the most important is one that Mary Gardiner identifies:

I mean, these things just seem like a potential minefield to me. And I don't mean legally, in the sense of people suing each other over bountified things that did or did not happen or bounties that did or did not get paid. I just mean in the sense of an enormous amount of sweat and blood spilled over the details of when the task is complete.

The point she makes is that it isn't possible to simply develop new feature x as a stand-alone piece of software and dump it into someone else's codebase. There is a great deal of bridge building that needs to happen on both the technical and social levels before a transfer of code is possible between a mercenary developer and an fortified project encampment.

These are the same kinds of issues a traditional closed software house has when they hire a contractor. Who is this contractor? What are their skills? Why are they being paid more than me? Will they incorporate into our corporate culture? Will their code incorporate into our codebase? Will they follow our development procedures and coding standards? There are plenty of ways to get each other off-side.

I consider it important to look for in-house talent. I don't think bounty systems should be geared towards the outside contractor, but instead to the core development team. I don't think bounty funds should be provided by the core development team to outsiders. Instead, I see bounties as a way for users of free software to contribute effectively to the core development team.

The Effient Software view of bounty collection and dispersion is that bounties are paid to developers who are already integrated on a social and techinical level with the core team. They may be full time or part time. They may work with other projects as well. This does not make them a mercenary. These are the people who don't come to the project just to do a single job. They watch the mailing lists. They spend appropriate time in irc channels and involved in other forms of instant communications for the sake of resolving technical issues. It is the core developer who should be rewarded for meeting the needs of the project's user base. It is the core developer who has the best chance of a successful development.

Finding the conclusion of the development should be straightforward and uncontraversial. It is as per project policy. The policy may be that an initial code drop is sufficient to collect a bounty. The policy may require a certain level of unit testing or review. It may require a certain level of user satisfaction. Because the developer is engaged in the policy process, the process is not a surprise or a minefield. Newer developers may be attracted to the project by successful funding of more established developers, and will have to break into the culture and policy... but that is to be expected when an outsider wants to become part of any core development group. The newcomer learns the policies over time, and the policies are as reasonable as the project needs them to be to both attract new blood and to fund the project as a whole. The interesting thing about open source is that if they get this balance wrong, it is likely they will be outcompeted by another group working on a fork of their software. The incentive is strong to get it right.

Money is a dangerous thing to throw into any organisation, and most open source projects get by without any dependable supply. There are real risks to changing your development model to one that involves an explicit money supply. I see rewards, however, and I see an industry that is ready to turn down this path. I think open source is the best-poised approach to take this path to its natural conclusion of efficient software production.

Benjamin

I was at HUMBUG last week, and was involved in a wide-ranging discussion. The topic of a particular closed-source software product came up, and a participant indicated that he maintained a windows desktop just to run the software. It was so good and integral to his work practices that he had a whole machine dedicated to it. He went on to criticise sectors of the open source community who tended to be irritated that closed source software was still in use. These are the sectors who have somewhat of a "with us" or "against us" view, and would prefer that closed source not be a part of anyone's lives. He asked (I think I'm getting the words right, here) After all, isn't free software about freedom of choice?.

I don't think it is.

Software alternatives are about freedom of choice. Whether the alternative is open source or closed source, the freedom of choice is not really affected. If I wrote a closed source alternative to Word, I would be providing freedom of choice to consumers. If I wrote an open source alternative to Word, I would be providing the same kind of freedom of choice. The difference is in the freedom of the customer once a transaction has been made. Open source software is primarily about post-choice customer freedom rather than freedom of choice, so it makes sense on at least one level for free software advocates to actively seek out unshackled alternatives to any closed source software they use from day to day.

In the software world we would traditionally see the freedoms of a consumer and the freedoms of a producer of software to be in conflict, however the foundation of open source development is to view the separation of consumer and producer as artificial. Freedoms given to the consumer are also given back to the producer, because the producer is also a consumer of this software. The barrier between consumer and producer exists naturally when only one entity is doing the producing. In that case the producer has automatic freedoms, and granting more to themselves has no meaning. However, consider the case of multiple producers. The freedoms granted to consumers are also granted to every producer when the production is shared between multiple entities. Open source produces a level playing field where entities that may compete in other areas can each limit the cost of this particular shared interest domain by working together.

When viewed from the angle of productivity improvement in a domain of shared interests, closed source alternatives can seem ugly and limiting. You will always know you are limited in closed source no matter how featureful a particular product is. You often can't make it better, and it would cost you a great deal to produce a competitive alternative as an individual. If competative alternatives exist you may be able to transition to one of the available alternative products, however you will still be in the same boat. You can't add a feature, and it only the threat you may change to another competitor that drives the supplier to use your license fee to produce software that suits you better. The competitors won't be sharing their code base with each other, so the overall productivity of the solution is less than the theoretical ideal. If the competitors joined forces they may be able to produce a more abundant feature set for a lower cost, however while they compete the customer pays for the competition. Which is worse? An unresponsive monopoly, or a costly war of features? Closed software represents a cost that the customer cannot easily reduce in an area that is different from their core competancies. It behaves like taxation from a supplier that does not need to outlay any more to continue reaping the benefits of its invesment, or a set of suppliers that duplicate efforts at the cost of the combined customer base. Open source may provide a third alternative: A cooperative of customers each working to build features they need themselves, and forking when their interests diverge.

People who are interested in open source are often also interested in open standards. Unlike open source, open standards do promote freedom of choice. Unlike open standards, open source does promote post-choice freedoms. Both have a tendancy to promote community building and shared understandings, and both are important to the health of the software industry moving forwards. The worst combination for overall productivity is and will continue to be a closed source product that uses closed data formats and interaction models.

Benjamin

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

Free Software is Efficient Software, but Efficient Software won't come into being overnight. The Efficient Software Initiative has hit another (small) milestone, in releasing its first project plan:

1. Conceive of idea
2. Promote idea via blogs and other viral media (we are here)
3. Build a base of discussion between individuals to agree on the right models for putting money into open source, including solid discussions on whether it is necessary or even useful
4. Build a base of three or more people across disciplines to begin developing concrete policy, business plans, and site mockups. Continue promoting and building awareness until at least one slashdot effect is noted.
5. Use wider promotion to get feedback on initial discussions and established policies. Learn which parts are defensible and which are not. Adjust as required, and begin building a core implementation group. This group will have access to sufficient funds between them to make the business a reality, and will likely have strong overlap with earlier core team.
6. Launch business based on developed plans

This plan is likely to require at least twelve months of concerted attention, and will likely strech over several years if successful. The ultimate goal is to build not only a business, but a business model that can be replicated into an industry. The goal is to fund open source development and directly demonstrate the cost differential to closed source software. If you have any comments or feedback on the plan, please let us know via the mailing list.

With it comes a call for participation on the project front page:

You can help us get off the ground!

Do you have a background in law?

Help us understand the Legal Implications of the Business

Do you have a background in business or accounting?

Help us understand the Profit Implications of the Business

Do you have a background in website design?

Help us develop possible website designs (this will help everyone stay grounded!)

Do you have a background in running large websites?

Help us understand how to set everything up

Do you have roots in open source communities?

Talk about Efficient Software! Get feedback! Bring people on board with us, and help us come on board with them

So, why should you get involved? Who am I, and why should you trust me to get a project like this off the ground? Well, I am not asking anyone to trust me at this stage. We are in the discussion stages only. The next stage is to develop a core group of people to push things forward. Perhaps that group will include you. If you really want to know about me, well... here I am:

I have lived in Brisbane, Queensland for most of my life now. I graduated from the University of Queensland with a computer science honours degree back in 1998. Since the time of my course I have been a involved in HUMBUG. My open source credentials are not strong. I have done a few bits here and there at the edges of various communities. I was involved with the sqlite community for a time and have a technical editor credit on the book of the same name. I have recently been involved with the microformats community, particularly with recent hAtom developments. I'm a RESTafarian. I have used debian linux as my sole desktop install for at least five years, and saw the a.out to ELF transition. I'm a gnome user and advocate. I'm something of a GPL biggot, or at least it is still my default license. I work in control systems, and have spent the last few years trying to "figure out" the web. I'm a protocols and bits and bytes kind of guy. I use the terms "open source" and "free software" interchangably. I'm afraid of license incompatability in the open source world leading to a freedom that is no larger than what we see in closed source software. I'm a father to be, with less than seven weeks to go until maybe I won't have much time to do anything anymore. I'm a full-time sofware developer who does a lot of work in C++. I work more hours at my job than I am contractually obliged to, so often don't have time for other things. I have a failed open source accounting package behind me, where I discovered for the first time that user interfaces are hard and boring and thankless things. That project came out of my involvement with gnucash, which I still think would be easier to replace than fix. I think python needs static checking because the most common bug in computer software is not the off-by-one error, but the simple typo. I haven't used ruby on rails because I think that any framework that requires I learn a whole new language needs a few years for the hype to cool down before it gets interesting. I render my blog statically using blosxom, partially because I didn't have the tools at hand for dynamic pages using my old hosting arrangements, but partially because I'm more comfortable authoring from behind my firewall and not allowing submissions from anywhere on the web. I used to be a late sleeper, but have taken the advice of Steve Pavlina and have now gotten up at 6am for the last six weeks straight. With all the extra time I still haven't mowed the lawn. I'm not perfect, and I certainly don't have all the skills required to create a new open source business model on my own. That is why I want this to be a community. I know how effective a community can be at reaching a common goal, and I think that the Efficient Software Initiative represents a goal that many can share.

So sign up for the mailing list. Get into some angry conversations about how open source doesn't need an income stream, or how selling maintenence is the perfect way to make money from open source software. I want to have the discussion about whether the kind of business Efficient Software is trying to build will create a new kind of free software market, or whether it just puts a middleman in the way of an already free market. Let's have the discussions and see where we end up. Efficient Software is something I can get excited about, and I hope it is something you'll be able to get a bit excited about, too.

Benjamin

Subject: [es] Free Software is Efficient Software

The Efficient Software initiative is growing slowly, but surely. We now have a wiki <https://efficientsoftware.pbwiki.com/>, an irc channel (#efficientsoftware on irc.freenode.net), and this mailing list. The post address is efficientsoftware at rbach.priv.at, and archives can be found at <https://rbach.priv.at/Lists/Archive/efficientsoftware/>.

We are looking forward to making positive connections with software projects, as well as lawyers, businesspeople, accountants, web site maintainers, and many more. To make this thing a reality we need to form a diverse community with a broad skill set.

The thing that will bring us all together is a desire for more efficient software production and maintanence. We can undercut the current players in the industry, and make a profit doing it. We can turn the weekend free software soldiers into a lean regular army with full time pay. We can match customer needs and pain to a speedy resolution. These are the goals of the Efficient Software Initiative.

Welcome to the community!

To join the mailing list, see the EfficientSoftware Info Page. A big thankyou goes out to Robert Bachmann for offering to host the list.

Benjamin

Efficient Software has launched its FAQ, currently still on the main page. From the wiki:

Why start this initiative?

Too much money is being funnelled into a wasteful closed source software industry. Initially it is investors money, but then customers pay and pay. Profits to major software companies are uncompetatively high compared to other industries. We want to funnel money away from the wasteful industry and towards a more productive system of software development. Free software can be developed, forked, changed, and distributed without waiting on unresponsive vendors. Free software is open to levels of competition that cannot be matched by the closed source world. Free software contributors don't have to be on any payroll in order to fix the problems they care about. Free software does not maintain the artificial divide between customers and investors. The people who contribute to the development of a free software project are its customers, and all customers benefit when bugs are fixed or enhacements are carried out.

What do projects have to gain?

Our goal is to increase the money supply to projects. Money is not a necessary or sufficient factor in developing free software, but it cannot hurt. Projects often accept donations from users, but it is unclear how much users should give or what their motiviations are. Efficient Software aims to tie a contribution to services rendered. Whether the services are rendered immediately or a year from now is inconsequential. Efficient Software maintains a money supply that can be tapped by projects when they fix the nominated bugs.

Won't this drive the wrong bugs to be fixed?

Projects will nominate which state a bug has to be in for Efficient Software to accept payment. Bugs whose fix would contradict project goals should never be put into eligable states and will never recieve contributions. One way of thinking about the money involved is as bugzilla votes. The difference is that modern world currencies tend to have low inflation rates and limited supply. There is evidence across a number of fields that when people commit money to a goal they tend to make decisions more carefully, even if the amount is small. If your project's money supply has a wide base, the dollar value next to each bug should be a reasonble estimate of the value to users in getting it fixed. This information system alone could be worth your while becoming involved.

What should projects do with the money?

Efficient Software was conceived around the idea that projects would pay developers for the fixes they contribute through a merit-based mechanism. We have some thoughts about how this could work in practice, but we will need to develop them over time. In the end, projects are required to make their own "opt in" decision with Efficient Software and their own decision about how to distribute the money. This policy will be made available to contributors in case it may affect their investment decisions.

What if a project marks bugs verified just to get a payout?

Projects are free to mark bugs verfied under their own policy guidelines. We do not get involved, except to publish those guidelines to investors alongside other policies. However, beware that any investor who has contributed any amount towards a bug will have their say on whether they believe the resolution was in the overall sense positive, netural, or negative. Cumulative scores will be available to potential investors in case this may affect their investment decision.

Benamin

The Efficient Software wiki has been launched. From the wiki:

This wiki is designed to concentrate efforts to create a new software industry. It is an industry that does not rely on delivering parallel services in order to fund software development or on the payment of license fees, but instead yields return as software is developed. It leverages the ability of a project's own bug database to bring customer and developer together. Efficient Software is intended to become a business that helps put money into the model. Its business model will be developed in the open and will be free for anyone to adopt. The product is more important than any one implementation of the business model. Cooperation is good, but the threat of competition is healthy too.

The fundamental goal of the Efficient Software initiative is to increase the money available to free software projects and free software developers. Contributors currently make donations to software projects, but it is unclear how much they should give and what their motivation is beyond "these are nice guys, I like them". Efficient Software is designed to create a market in which customers and projects can participate to meet customer needs and project needs.

Have at it!

Also, I would love to hear from anyone who is prepared to host a mailing list for the initiative.

Benjamin