Funding Open Source

I have no problem with Bodo getting some compensation for the work he has done (he did good work), however, I keep thinking about Public Domain software and Open Source. I have heard many utopian idealist expound on for days about the benefits of Open Source and how it is great for the computer industry and how it will change the world. There are thousands of programmers cutting code on many Open Source projects and I must ask, "what kind of compensation do they get?" Bodo, charge what you wish, but I would like you to consider for a moment the path you are taking. It seems you are turning a open source idea into a commercial venture. It seems like someone who has done the work you have done, would be in it to help advance the software development community, not to go public and lose millions of dollars when the NASDAQ turns South again. Remember what the internet was like before it became commercial. Yes the internet has much value now, but before it's transformation, it was so much more pure, simple and innocent. I think the Open Source movement is the same innocent, fragile seed trying to grow. Many programmers like you are making decisions on a daily basis to keep their code secret or to plant their code in the Open Source field and see if it will grow. Anyway, enough ramblings on from me. Good Luck with your decision. I will respect your decision either way. -- I am ScottBlalock

Scott, Do you have any suggestions about how to finance ones cost of living as a full-time open source programmer? How many people will pay for something that they can legally use for free? If you earn your living by writing open source software, I would be happy to learn about your business model and apply it to vbUnit3. -- BodoMaass

Bodo. Get one of those silly american process patent things. I know it's more cost, but then Mr Gates will bang your door down and you can do something new. Relying on generosity is unlikely to pay the rent. If that means making your product non-free then go for it. The model I have always favoured is the "free old version, expensive support and updates" option, which looks like the path you are looking at. Good luck.

I am facing the same thing with JUnit. I have a house/college/kids shoes to pay for, and consulting work is slow. I'd like to work on JUnit, but I can make more writing a book. The FreeMarket'er in me says this is the market's way of telling me a book is the right thing to do. --KentBeck

While I wouldn't want to talk Kent into a plan that makes his kids have to walk around barefoot, I would argue that the market isn't necessarily gonna tell him the right thing to do. Then again, I have no satisfactory answer to the question of how you fund open source development. I believe there is such a thing as karma, and it seems like open source karma manifests itself often as book contracts. As much as I love books, though, I love software better, because the benefits keep multiplying so easily. It's just unfortunate that the developer never quite sees his fair share of the benefits. So, Kent, I hope you improve the software, but I understand if you write the book. -- SteveHowell

KentBeck's books probably helped many others make a better living. That's good karma. -- PohhengTeoh

Is it possible that there is no money in software anymore, period? That all the software companies are dinosaurs, and the final extinction has not quite arrived, but you can smell it coming? Open source is just a symptom. Who are the mammals?

I think packaged proprietary software is slowly going to fall by the wayside, as we get more and better open source alternatives. I think the next ten years will be about hardware, with more and more innovation in palmtops, cell phones, PVRs, etc. As hardware companies compete for customers, they will fund open source development to ensure that their software is usable as quickly as possible. There will be a spectrum among hardware companies, though. If a hardware company is building a product where the hardware is difficult to duplicate, they are more likely to open up the software. Other companies will build boxes that just combine a bunch of existing componennts in an innovative way, and these companies are more likely to keep their software proprietary. -- SteveHowell

Excellent! Could you introduce me to one of these hardware companies? --KentBeck

Sorry, still ten years away. ;) I think that the folks behind iPaq are getting behind Linux, but I'm not sure that they're actually funding anything. If you want to write device drivers, you can probably work for a company like Backpack, which I believe has paid its employees to work on open-source drivers for Linux, although I suspect that's just a small piece of what those employees do. Take my speculation and wishful thinking with a grain of salt, of course. I want open source to be funded, but I haven't found that funding myself. -- SteveHowell

The Oct 29, 2001 issue of Computer World has an article on IBM's investment in Linux and open source. According to the article, IBM is spending "more than $1 billion this year alone", and has "more than 250 developers working full time on Linux and open-source projects and has thousands of employees, from sales to Global Services, trained on the operating system". -- RichardBash

There's no future for Open Source unless it comes up with a sustainable economic model soon. It will die like the DotCom's did. -- AnonymousCoward

I disagree. OpenSource (or FreeSoftware to be more precise) existed long before the DotCom's, and should every company involved in it die today, FreeSoftware would live. Remember we're not talking about a company, but about a movement mostly based on voluntary work; it can't go into bankrupcy. Sure, if the LinuxKernelHackers? were not employed full-time to work on the kernel by their respective companies, the development would slow down a lot, but it would not halt or disappear (it happened before, Linux did not wait for RedHat to exist). The only real threat I see are DMCA and friends, which could make it illegal to develop free software (although only in the US for the moment).

Well, it matters a bit what your definition of "life" is. If "death" requires that the free software be deleted from the universe, then I think that Free Software will live forever. If "death" requires that no one use it anymore, then I think that Free Software will live forever. If "death" requires that no one maintains it anymore, then I think that Free Software will live forever. But if "death" requires only that no new Free Software projects are created, then Free Software could die. (And subsequently come back to life, and die again, and come back to life again... depending on the economy.)

Here's a short discussion about some funding mechanisms: http://www.advogato.org/article/377.html

The last posting by Malx in that discussion feels right. For software with any kind of GUI, you could have a "Contribute" menu item, or button somewhere on the main window of the software. When you click it, you get a window containing the current "todo" list for the software, with a payment submission button next to each item on the list. If you click on a todo item, your web browser pops open to display a credit card payment page on a Feature Broker site. Using a micropayment system (PayPal?) could make this even easier.

Once the software maintainer implements a feature on the todo list, he makes his software release, and the Feature Broker service verifies the feature was implemented, and releases the accumulated funds to him for that todo item. Then the todo item would be taken off the Contribute window for the package. Users would need a mechanism for adding features to the todo list, probably again through the Feature Broker service.

You could even have a general donate-to-the-cause button if you don't have any specific feature request. In a way, this could also be a sort of popularity vote for software activists. In keeping with the spirit of openness, the Feature Broker would allow folks to browse the stats for all software maintainers - how much money have they made, how snappy are they about implementing features, etc. If desired, the folks contributing money could be viewed as well.

If 10,000 Apache users each donated $1 to get some known bug fixed, it would seem like a reasonable expense for users, and a good motivation for the maintainers. Maybe businesses would setup accounts with a Feature Broker and pledge some periodic amount. This might work like sponsoring an auto racing team - good advertisement. Just look at the overflow of love for IBM since their "$1 billion on Linux" announcement.

It would seem this mechanism would preserve the independence of the OpenSource or FreeSoftware maintainers, but also give them user feedback on desired changes, and a means of getting paid to work on the projet. On the other side, users get an easy way to say thanks, or help get changes made. A side effect would be publicizing who really gives more than lip service to OpenSource.

- EricRunquist

Addon to the above: for software packages that use a large number of non-GUI components, like libraries, the "Contribute" menu could display all the OpenSource software used to build the package. The software's author could list the libraries he feels most deserving of funding, and that contributed the most to his software's success. This could include binaries incorporated into the software, as well as tools used to generate or execute the software, like compilers, interpreters, etc.

- EricRunquist

I think BradCox outlined the basic nature of the solution years ago -- an economic infrastructure, similar to the way a power company reads meters, that supports a BMI/ASCAP-style royalty structure. OpenSource code is exchanged based on its conformance to a unit-tested API. Revenue is collected from users (who receive a monthly information bill) and distributed among the suppliers based on some mix of procedure calls and storage utilization. The grain size is intentionally very small (down to the smallest element that is readily testable -- probably the method). The result is self-billing software. This approach turns the easy ability to copy bits from a liability into an asset.

OpenSource developers who know how to solve a particular (and small) problem very well can put their self-billing solution into circulation and rely on revenue based on its behavior in a competitive (with other solutions that fit the same interface) environment.

-- TomStambaugh

That's an interesting idea. I suspect the infrastructure and forced payment mechanisms would scare people off. Basically this would take the "free" out of free software, since users will be required to pay for using it. Forcing people to pay puts the users and developers at odds. It seems like we need a way of aligning the needs of the users and the developers.

software is extremely inexpensive to copy - users should not pay for each copy of software
software is extremely inexpensive to run - users should not pay to run the software
software is expensive to develop and maintain - users should pay for development and maintenance
software can be expensive to configure - users should pay for custom configuration services
providing support for software can be expensive - users should pay for personalized support

It may be that RedHat and pals have found the solution. They put their name on a collection of software they distribute as a package. You can download the distribution for free, but if you want a nice manual and support, you buy a shiny RedHat boxed distribution. If users of the distribution complain, RedHat has motivation to get the problems fixed (since they want to sell more shiny boxes), and money to do it (since they have already sold some shiny boxes). At the same time, the software remains OpenSource. Maybe these "distributions" will become the Feature Brokers I described above.

-- EricRunquist

Open Code Market

(like "Feature Brokers" described above)

 Proposal: http://firstmonday.org/issues/issue8_11/munoz/index.html
 Site: http://www.opencodemarket.org/

One potentially successful revenue model for OpenSource is SellTheDocumentation.

Some other ways to fund Open Source:

Street Performer Protocol / Hostage-Ware -- where the author releases the program under a closed license, keeps publicly-visible records of all purchasers and the total revenue (and each purchaser can verify that he hasn't been left off), and promises to release the program as free when the total revenue exceeds a certain pre-set amount (perhaps $60,000 for every year he spent writing the program). The amount has to be written in the license to avoid MovingGoalPosts.
Timeout-Ware -- where the author releases the program under a closed license, but embeds a date directly in the license, the date at which that license will expire and an open-source license will take its place. His ad campaign can basically be, "It'll be free on (e.g.) July 1, 2003, but why wait? Start using it and modifying it now for only (e.g.) $49.95!" And he can gradually cut his prices as the date approaches.

The one thing that wasn't discussed about the model for open source is that corporations are jumping on the bandwagon to fund the creation of it. This doesn't mean that KentBeck will be out of work, he will simply have to get a job at a Fortune500 company and work 8 to 5. OpenSource will have an effect on those who have traditionally made money as consultants or those who work for small startups. -- JamesMcGovern

Two Questions:

If I pay for a piece of software (using whatever mechanism you care to come up with), how can I be sure it is OpenSource and not CommercialSoftware? (Please don't say you get the source, you can get CommercialSoftware? source, ie source code escrow, etc)?

At which point can I take all the source code contributions from hundreds or thousands of programmers, claim it mine, put a price tag and a copyright on it and sell it. How much functionality do I have to wrap around other programmers work before it becomes my property?

-- I am ScottBlalock

If the software was released under the GNU GPL you could only add to it and sell it if your additions are GPLed also, otherwise you would be breaking the law; however, you could keep changes as proprietary as you like if the software is used in house only. Other licenses are more flexible in that they allow proprietary wrapping of open source software.. which is what Apple did with the proprietary GUI wrapping a BSD open source UNIX core in their current OS. Most EndUsers? just see the GUI and don't have a clue about the open source core. See: GnuGeneralPublicLicense and BerkeleyStandardDistribution and OpenSource. -- RonJandrasi