| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

FrontPage

Page history last edited by PBworks 14 years, 2 months ago

Free Software is Efficient Software

 

The Efficient Software project is designed to support bounty-driven open source software development. We are looking for legitimate open source projects to open up their bug databases to ad hoc bounty creation by users who want to scratch an itch, but do not have the time or skills themselves to fix the bug or make the enhancement.

 

We want to create a new open source software industry that does not rely on selling parallel services such as support in order to fund software development. We believe that open source software is the most efficient and economic form of software. Open source software is fundamentally about saying "You don't have to pay for this software, because those who needed the features more than you have already paid for their development". It is about saying "We who need the next feature can collaborate freely to provide resources towards it". We believe that allowing the user community to form a bounty around a particular objective should become as much a part of the open source process as getting together as a group of developers and writing the code for it.

 

We are committed to promoting a funding model for open source mass market software that achieves in-phase incentive-based returns for developers. We believe that an approach or a family of approaches to meet this criteria can be developed. We want to be the place that it is developed.

 

If you have an idea or approach that fits the criteria or are working on opening up your bug database, we would love to hear from you and discuss things further on our mailing list at http://rbach.priv.at/Lists/listinfo/efficientsoftware (archive).

 

Mass-market Software

We are interested in ideas that serve a mass market. Software developed for a single customer or a very small group of customers is unlikey to achieve economies of scale that make adding an efficient software process beneficial. We are interested in software that has a sufficient customer base that customers can achieve mutual benefit and lower costs by cooperatively funding development. We believe a single customer should benefit from both the rewards of their own investment into a software project and of the investment of others into the software project.

 

In-phase and Incentive-based Returns

We believe that the separation of an investor and a customer in traditional closed-source software is an artificial and inefficient one. The split is driven by a develop/sell cycle. An investor trumps up funds or other resources for the intial development, then costs are recouped after a software release by sales to customers. We want the development of software enhancements and of new features to be driven directly by customers and paid for before the release. We believe this will yield a more efficient software development process, and fits both with open source and with agile software development methology.

 

Open source

We believe that the future is open source, because that future provides most beneifits to the customer base. If the barrier between the customer base and the investor base can be broken, it follows that open source provides the most benefits to our investor base. Open source licences act as an free trade agreement between customers that guarantee that no single one benefits to the exclusion of others. If software development costs can be recouped before release time a separate product licencing scheme to bring in more funds may be unnecessary.

 

We see an open source implementation as an absolute good in the context of Efficient Software. Another key benefit is the ability of parts of the customer base to fork the project should their interests diverge. This can be done without abandoning prior investment in the software base, meaning that such investments can be made securely.

 

The Working Model

 

Our model leverages the ability of a project's own bug database to bring customer and developer together. A single customer will raise a bug corresponding to a user story. The project team will accept the bug as legitimate and ready for funding. That customer and other customers can contribute to a pool that funds development into the bug (a balanced asset and liability account in the project's ledgers). The pool is never exhausted until either the project successfully closes out story (the liability is cleared), or all funds are returned to investors and the bug abandoned (the asset is returned).

 

This model will be developed and expanded in the open and will be free for anyone to adopt. We will act as a central information hub and may add additional support, including but not limited to:

  • Branding, logos, and additional information campaigning
  • Development or housing of software that makes hosting an efficient software project simpler
  • Developing useful investor information indicators, and aggregating them over known efficient software projects

 

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.

 

Edits

To edit this wiki you need to use the wiki password of "es". Feel free to clean up any wiki spam you see. If you want to contribute to any of the pages on this site, log in and have fun. All pages should be considered draft initially. We'll hammer out the details in the mailing list and on irc. After that we can set about a formal write-up process.

 

Origins

Efficient Software originates from a series of blog entries by Benjamin Carlyle:

Discussion at the Home Unix Machine Brisbane User Group helped to develop the foundations:

It transitioned from its original model of centralised business and clearing house for funds to one of decentralisation with this email:

 

Prior Art, earlier work

Money has been directly awarded for the closure of bugs before in bounty systems. Please add experiences and examples to this list:

 

The Efficient Software Initiative differs from most bounty systems because it is designed to allow customers to reward projects and their developers rather than to allow projects to bring about fresh blood.

 

Project Plan

See our plan for developing the Efficient Software initiative into a business that supports open source software development.

 

Call for Participation

You can help us get off the ground!

 

Do you have a background in law?

 

Do you have a background in business or accounting?

 

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

 

FAQ

Add questions to the FAQ for answering. We will endeavour to get to them as soon as possible. Add sub-headings to this section.

 

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 may be a useful one. 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. You may be able to improve your developer pool recruitment when you choose to distribute money earned to those who contributed to the relevant fixes.

 

What do investors have to gain?

Efficient Software could be an efficient way to employ open source developers without putting them on the payroll. All payouts are outcome-based, operate within established low risk project infrastructure, and add to existing non-monetary project incentives. It provides an easy way to coordinate investment between organisations and individuals who desire a particular bugfix or enhancement. Working in the open source world means that you could fix the bug with your own resources. You could wait until someone else expends their own resources on a fix. Efficient Software is the third alternative, to coordinate incentive and compensation for someone who is already involved in the project: Someone who is willing and able to perform the fix. If your bug or enhancement request is preexisting you can avoid getting deeply involved in project workings and politics.

 

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.

 

Won't this drive projects to release buggier software?

All bugs are not created equal. Users of the project will decide by the rate of investment which bugs are worth more and which are worth less. If the quality of software drops, so will your investor pool. Driving off investors and driving off users are the same thing in the Efficient Software landscape. Keeping one happy is the same as keeping the other happy.

 

Rather than producing buggier software, the efficient software initiative should see projects raising more future work as bugs to be resolved. This work will be an investment driver. As fewer new features have to be added, software projects will reach a point where investment declines. This is a natural phenomenon for software that is effectively finished. Some developers will stick around to fund bug fixes, while others may move on to more current visionary work. In fact, many developers will be involved in a combination of both.

 

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 recommend projects publish those guidelines to investors alongside other policies. We believe that any investor who has contributed any amount towards a bug should have their say on whether they believe the resolution was in the overall sense positive, netural, or negative. Cumulative scores should be made be available to potential investors in case this may affect their investment decision.

 

Can projects artificially inflate the price of bugs?

In the short term projects may be able to achieve a higher bug value by waiting for bugs to reach target prices before tackling them. They may even generate fixes and wait before committing them or before creating a release in order to get the most out of the Efficient Software revenue stream. To some extent this will be expected behaviour. If the Efficient Software model is to become a viable alternative for the paid production of software it is important that developers can eventually earn a living wage. Customers will likely put up with very little deliberate obstructionism, however. They may refuse to commit further funds and find other more efficient software projects to invest in. In extreme cases of obstructionism another software team may fork your project and seek to outperform you. Chances are they'll take some of your team members with them.

 

The threat of forking is essential to ensuring productivity in software development. It is the lack of this threat that dogs the current industry and prevents it from becoming efficient. Successful Efficient Software projects will quickly find a balance as to how aggressively they should attack bugs once money has been committed. The Efficient Software web site will track this efficiency as the average number days it takes to clear a dollar from our bank accounts and return them to yours. Projects will be compared and contrasted, and these numbers may influence decisions made by investors.

 

How could Efficient Software be involved in the development of new software?

The need for a particular piece of new software can be modelled as a bug. There are three options as to where such a bug would be raised:

  1. In a new project bug database, newly opted-in
  2. In an existing project bug database
  3. In an existing "project foundry" database

The best results may be achieved by leveraging the reputation and experience of an existing project. We may find that specalised project foundries eventually form, where specialists in project formation and kick-off accept bugs that match the need for new projects with new goals. They may verify the bug when a new bugzilla is formed for the project, and sufficient support exists for the project to become self-sustaining.

 

More likely in the near future is for new projects to begin life as part of an exising project. Beware that this may lead to some existing project members moving on, but for projects of a certain critical mass this could make a lot of sense. Remember that by verifying a project creation bug you are exposing yourself to negative feedback should it fail. New projects are the highest risk category of bug.

 

Why will Efficient Software succeed where SourceXchange failed?

SourceXchange opened for business December 7, 1999 and closed its doors April 6, 2001. There are lessons to be learned from this collapse and we should learn them well. According to its press release SourceXchange failed due to lack of volume, so it is important we provide a model where the cost to build volume is low. The SourceXchange Process centered around the development of new projects, the coordination and fostering of those projects internally, and was involved at every step of the way. Efficient Software will operate on an arms-length collaboration with self-started and self-organised projects. Efficient Software will measure and report resolution based on a project's statement of resolution, and measure the effectiveness of the resolution based on investor satisfaction. By focusing long term relationships and non-invovlement we hope to drive the volume of transactions up in proportion to the number of open bugs in the free software world, and keep costs low for each transaction. Most costs are likely to be incurred when we individually take on new projects.

 

How do you compare to Bounty County?

Efficient Software is a model for generating bounties on existing project bugs, and payout to the project when bugs are fixed. Bounty County is an aggregator for bounties hosted elsewhere, typically by software projects themselves or by other individuals or organisations. The Bounty County web site is clean and efficient, and may form a model of the way aggregation should look on an Efficient Software site.

 

If a project wants work to be funded via the Bounty County system, they must trump up the cash. They then publicise the bounty, and Bounty County is one way of doing that. They hope that new developers will start to participate in their projects and yield appropriate benefits to offset any costs of the bounty. In contrast, the ideal of Efficient Software is for a project to simply "opt in". They raise bugs for things that are important, and may publicise the important bugs by various mechanisms. One may be through Efficient Software itself. As more people dedicate money to the goal of a particular bug fix it will rise higher into the attention of the Efficient Software user base. In theory, this will accelerate the amount of money available to the bug. Once the bug is fixed this money is paid out the project. Our ideal is that most of the money goes to the developers who contributed to the fix.

 

Our model is that existing as well as new developers can benefit from bounty payout. We intend that new developers be attracted to projects in proportion to the available money supply, as well as by other factors such as "fun". However rather than a simple recruiting drive, Efficient Software is conceived as a means of funding project development.

 

Buzz

Who is talking about Efficient Software (add to list)?

Comments (0)

You don't have permission to comment on this page.