A Comfortable Couch

Thursday, September 30, 2004

Open Source Couch

This is an email I received from Brendon Upson, creator of Puakma. I thought his questions were good ones, and I wanted answer on my blog. With his permission here is his email and my response (rambling thoughts really).
Hi Damien,

I am a bit puzzled by your Couch project, well not so much the project but how you plan to fund your long-term existence. You mention that you're going to make Couch opensource (GPL I guess?) which is all well and good but have you thought about revenue models for the software? Your time costs a lot of money and unless you're hideously independently wealthy you're going to get very hungery at some point. Couch sounds like software that will take years to mature (Puakma is now 3.5 years old and just starting to reach maturity).

I came very close to making Puakma opensource, but really the GPL'ed business model is terrible for us small guys (just look at Red Hat!). If your idea is a monster winner, then IBM with their monster marketing budget can simply pickup the project and usurp you simply by their size. You put in all the effort, they get all the revenue. Not fair. Once the code is out there you can't take it back.

my 2c. I'm happy for you to convince me otherwise...

Brendon.

First of all, I'm not wealthy. Not even close. Therefore I'll need to make a living at some point. How can I make money on Couch if I open source it?

Well if Couch really rocks and many companies are willing to pay real money for it, then I will probably start a traditional company. Or sell it to another software company for a nice price. Sweeeet! But this is fantasy land, its very rare for a new product to have this kind of intrinsic demand. It's even rarer for enterprise products.

So if I don't have that kind of demand, then what?

The Closed Source Route

Let’s say Couch is good, it hits some sweet spot that makes it useful and it solves real problems.

If it’s closed source, then I have to think about ways to sell it. Like the vast majority of software out there, people won't know how good it is or if it solves their problem. Build a better mousetrap, and the world doesn't notice.

Even if I give a nice long free trial, few people are actually going to download, install and configure it. Ever fewer will actually end up paying money. This is a simple reality. So that means I’ll have to hire sales and marketing people. Selling software to enterprises is hard work, at least from what I've seen so much of enterprise software sales is plain old shucking and jiving. And then you have to worry about creating formal support, HR, accounting, etc. And if the product isn't quite what customers need, then you have to pester them to tell you why, they usually won’t tell you on their own.

All of that requires capital to get you through the startup phase and it requires a lot of work. Of course I can try to build a business without all that overhead, but that overhead is there for a reason, the product won't sell itself. I can try to become a one man show, trying to sell, support and extend the product by myself, and try to make some money while I do it. That's a tough way to make a living.

The Open Source Route

What if I open source it, what’s down that path? I'm not sure, but here are my thoughts anyway.

Firstly, what open source license model to choose? Well, obviously I’d like to choose the one that gives me the most benefit. I don't like the GPL because it puts tons of restrictions on what people can and can't do with the code, including me, and I don't want anything telling me what I can do with my code. So for me, the best license is probably none, I'll just make it public domain.

The reason being, I think it’s the least restrictive for me. This seems counter intuitive, but my reasoning is I can at anytime become closed source. That is to say, I can at anytime stop giving away modifications.

If Couch becomes very popular and I want to start a closed source business, then I just stop adding enhancements and fixes to the public code base. All new features just stop being released to the public by me, then I sell the newer and better closed source software at a moderate price. Some people will pay to upgrade, some won't. Some other people might continue to maintain the old code base, and I'll probably continue to fix critical bugs on that code base as well (oh look at me, I haven't even built it yet but I'm already thinking of my legacy users... because I care).

But as long as it’s free open source, it will enjoy some advantages that will help its long term success. People are more likely to try it out and start using it. They'll feel good knowing they can try it out and not have to worry about uninstalling it should it become useful. They install it, they own it.

Also feedback should flow more freely, which I see as fundamental for any product’s success. I see two reasons why open source is better at getting feedback:
  1. More people will be willing to try out the product. More people means more chances for feedback.
  2. Psychologically people will be more willing to give feedback since the feedback won't be going back to a closed off moneymaking venture, but instead it goes to an open community.

I don’t know those to be true, I’m just guessing (and hoping).

Of course, one the biggest perceived benefits is that anybody can hack the product, they have all the code to build on just like me. They can find and fix bugs and code up new features and give them back to the project. I think in practice this doesn’t really happen that often, but it certainly happens more than in closed source projects.

Also, consider that sometimes software will only be successful if it’s free, $0 is all the market is willing to bear. If that’s the case, then I might be able to make money on complementary closed source products, like admin packages or backup tools.

Can Some Company Steal My Success?

By putting it in the public domain, other companies can also make their own closed-source products out of it. Let them try! If I decide to go closed source too I have a advantage over them, its my code. If they are selling to my customers, then I can copy their functionality, only I think I can do it better because it’s my code base and I'm going to be most a home in it ( good luck getting through my dense, perplexing code...bwaahahhaah!).

If they do a better job, then so be it, hats off. But it would have to be MUCH better in some way to get people to stop using my code base to go to their other proprietary code base. Why? Partly because Perceived Success Breeds Success, and customers will tend to buy from the guy who built it, because that code path will be seen as having the best chance for long-term success.

If the competition isn’t selling to my customers but instead some different unexplored market and they’re successful, then I always can move in and try poaching their customers. They’ll do the work to find and validate the market, and then I can reap some of the benefits.

If Couch is such a success that the big boys (IBM, MS, EMC, etc) want in, then fine. Another big boy can hire me (at a fat salary) and build a competitive offering, and the company that hires me will have the perceived advantage, rightly or wrongly.

So even though people will be able to build a business on top of my work, they'll have a hard time competing head-on with me, I’ll have a natural advantage, and so will those whose working with me.

I don't think hiding away your source code is generally such a big advantage. It’s certainly a big monetary advantage if you have a wildly successful product, it’s like a license to print money. But if Couch is wildly successful, then it will be hard to imagine that I can't cash in some way on that success even when the code is open sourced, I’ll have many money making options and opportunities. I might not get as rich as I could have, but I'm sure I can do pretty well.

But for the much more common case of mild success, I don't see that it offers much advantage at all. If others see opportunity and create a competing product, then I can compete with them and I'll have a natural advantage. If they are much better funded than I am, then I can look for investment capital or a larger company to help me compete.

What If It Sucks?

One thing I haven’t mentioned is what happens if the product isn’t successful. Like success, there are degrees of non-success.

It might be unsuccessful because it just doesn’t solve any problem that isn’t already better solved by something else. In this scenario the product works, it has nearly everything I aimed for, but other technologies or products do it better, the code is good but the product is not. In this case, it might help me land a really awesome job, people will have no questions about my engineering skills, they can just look at my work to see what I can do.

Or maybe it will help me get high paying consulting work that allows me to work part time and I can start working another kooky project. I’ll have some rare skills (knowledge of NT file system drivers, for example), that might be very in-demand. When all is said and done, I see this as being pretty strong possibility for my future.

However it might fail because I simply wasn’t good enough to build it. In that case, I’ll change my name to Dirk Savagewood and start wrestling alligators. That could be fun.

6 Comments:

Colin Pretorius said...

I think many people would advise you against renouncing your copyright altogether - have you considered using a BSD/Apache style license? That way'd you'd meet your objectives without the GPL restrictions, and you'd still "own" the code legally as well as morally.

11:26 AMlink  
Anonymous said...

A book you might want to check out is Open Source Licensing (http://hostit1.connectria.com/twduff/home.nsf/plinks/TDUF-64L2RC) by Lawrence Rosen. This goes into quite a bit of detail about the different types of licenses and what you can do and not do under them. It also talks about how to structure a business around an open source model...

Duffbert
http://www.twduff.com

11:46 AMlink  
Anonymous said...

I think you'd be making a big mistake by choosing the Public Domain route, judging by your stated goals you really want to release your code under the GPL, as it doesn't stop the original author/copyright holder from doing anything they want to (a common misconception). Because you are not bound by the GPL for your own code, you tilt the playing field strongly in your favour by using it for everyone else, as compared to BSD/Public Domain.

The benefits:

* you can dual-licence the code in any way you see fit (usually a choice of GPL or a standard payment option like MySQL offers, but note that Mozilla for example is triple-licensed GPL/LGPL/MPL.)

See http://www.mysql.com/company/legal/licensing/faq.html
and http://www.mozilla.org/MPL/relicensing-faq.html

* no-one else can release a closed source version of your code (unless they reach a separate agreement with you and meet your terms)

The caveats:

* a big commercial company (e.g. IBM) could still compete rather than collaborate with you, making use of your own code, as long as it is a GPL'd open-source product. However, it probably wouldn't make any sense for them to do so as long as you were still actively maintaining the project.

* you cannot build upon other people's GPL code as if you do so you will always be bound by the GPL for the code written by others.

* if you seek community input you will need to ask contributors to assign their copyright to you, allowing you to sell a close sourced version of their code.

Finally, I'll note that in my opinion it would probably be easier to build a consultancy career on top of a successful free software product than attempt to make money by taking it closed source. Why kill the goose that lays the golden eggs?

5:10 PMlink  
Damien said...

I am aware of the BSD license and I like that I would get credit everywhere that Couch is used, but I'm not sure if that really helps Couch.

Thanks for the book suggestion, I'll definitely look into it before making a final decision.

I didn't know you could use the GPL and keep the copyright. I read up on it and I still don't quite understand how it works exactly. That's part of the problem, its hard to understand it and its nuances. However I don't like it for other reasons as well. I don't like that it restricts what others can with the source code. Really, I want to give Couch the best possible chances for success, and I'm not sure if the GPL and other restrictive licenses are better than public domain or BSD for that. At least for me and Couch, that is.

11:10 PMlink  
Anonymous said...

Interesting entry... however, I wonder if this adequately addresses Brendon's questions about the business model itself. You've addressed it mostly in terms of invention-centric terms, such as weighing open vs. closed source etc. but is there a recurring business model as well? You're probably reading a lot of recommended things these days, robbing you of precious time to work on your project, but I'm reminded of the book Built to Last and it's distinction between "clock builders" and "time-tellers".... Instead of being invention-centric, have you approached what you want to do from an organizational standpoint? I.e. not as dependent upon one particular invention but more of an overall, ongoing effort? (I'm trying to avoid fluffy/abstract terms like core values and mission statement but they serve just as well I guess.) Eg "to increase efficiency and decrease failover rate of file servers"... this can help to prevent you from getting side-tracked into becoming an NT file systems guru, something that should really be an accident of the overall effort. It also frees you from being shackled to your own solution, and any potential shortcomings it might have (yet undiscovered, or imperfect compared to other solutions you can acquire for this overall purpose, later on).

http://mitpress.mit.edu/books/NORVH/chapter1.html?isbn=0262140659
That is a sample chapter of a book that is probably the best reading on this topic I have come across so far.

Can you find a customer before you invent the product he should buy? and sell it to him first, even (to share some of the risk- much as an employer would).

I'll be rooting for you and wish you the best of success. I was slightly concerned about your leaving one job, but then suddenly becoming available for contract work. You might be able to choose your own hours, but in Ned's terms of breaking your shackles, isn't it kind of like putting on new ones (with new/unfamiliar stresses)?

--David Boudreau

1:19 AMlink  
Anonymous said...

Couch looks a lot like the GoogleFS. There's an attempt at making it in the DRBS project, which you can find on http://freshmeat.net/projects/drbs/

1:11 PMlink  

Post a Comment

<< Home