Hacker News Reader

Comment by fletcher | Hacker News Reader

I don't trust this model, since when building a company that's based on open source software you have just two business models available:

1) make money from services.

2) make money from products.

If you pick "1" you can do a good, very small company, to get your bills payed, but service companies are hard to scale, and unlikely to grow their value in a short time. This is not what your VCs have in mind, basically.

So you end doing "2" if you are VC-backed. With "2" the only way to get money is to either close part of the software, or to find a different way to provide some product value to the user if the use will pay. And this will make the project weaker one way or the other in the end.

p.s. I need a new fake account.

View on HN

Model number 3:

That is what I'm doing with Redis. If the big company funding the project is as polite as VMware you end with a lot of freedom but the money to just focus only on your project (and not just you, VMware just hired Pieter Noordhuis for instance).

Only disadvantage is that the lead developers are unlikely to get rich, as they are payed to work with a good salary but this is not like a big exit for a startup. But my grandfather and my father always got payed to work, so I trust this model, and I'm not seeking richness, so it's the perfect model for me, but not for everybody.

Amazed to see the author of hping2 here .. ah that was a different era ;-)

I remmeber him from his tcl days and I love the guy.

this shows an amazing value system:

" But my grandfather and my father always got payed to work, so I trust this model, and I'm not seeking richness "

they are payed to work

FYI, the correct spelling in this context is "paid"; the spelling "payed" is only used in a couple very obscure cases which you'll probably never encounter.

(I'm only mentioning it because I'm pretty sure you're not a native English speaker, and I figured you might like to know.)

> service companies are hard to scale, and unlikely to grow their value in a short time. This is not what your VCs have in mind, basically.

It depends on your services I suppose, but I don't think it would be especially hard to generate revenue by selling Nginx training and support. A conference, seminars, books, support contracts, etc.

Sadly just having an official company behind it will be enough to get approval to use Nginx in a lot of enterprises--sign a fat support contract so you can cover your ass and not think about it again.

>Sadly just having an official company behind it will be enough to get approval to use Nginx in a lot of enterprises--sign a fat support contract so you can cover your ass and not think about it again.

I foresee that plugin writers and source contributors will slowly creep towards the consulting and support model, while the 'community' or 'core' version users will get scarcer documentation. That's fine by me, but signing that support contract will probably mean paying 2 grand for getting a tailored nginx.conf and an SOW document.

That's a good business opportunity overall, but at what cost to the community ?

Almost no cost to the community, this option is far better than MySQL route.

There are hardly any source contributors to begin with. Igor is notorious for being very slow to accept patches for anything but simple bug fixes, it's only recently that other people have gotten access to SVN, or that the SVN was even public.

Meanwhile the nginx wiki is completely community run and maintained. The nginx company would cripple itself if it ostracised the community behind it.

PuppetLabshas found that #1, being a services company, really sucks. There's less of an impetus to do a good job at maintaining your community since you're directly competing with them. The realization that their documentation is somewhat sub-par, and that they haven't really built the community that Chef has is why they're shifting to being a products company with their hosted offerings.

Perhaps Nginx can learn from that, and maybe build out some hosted products, like selling self-scaling nginx ami clusters on ec2.

Webservers are a hard business to make money in. Look at Zed Shaw, he built the app server that made Twitter possible, and I'm quite sure he never saw a dime out of it, though it increased his reputation. Likewise Igor hasn't seen money out of nginx yet, but he's built software that also helps enable hundreds of millions of dollars worth of transactions per year of business. He deserves the opportunity to profit on the technology he's shared with the world for free.

With a service company, you have an incentive to make your product confusing and your documentation poor.

this is a good "two months" strategy. After a few months no one will want your product.

What if people are already using your product despite poor documentation?

Then what's your motivation to make the documentation better, and the abstractions easy to understand?

At worst, you could simply believing that you work in an inherently complicated field where people must pay for services and training just to get by.

nobody can stop you from doing a bad service company, but no one can stop you from doing a bad product company as well IMHO. The difference from an open source point of view is that the community can write better documentation, but can hardly fight you if the open source main developers are trying to push forward a business model where part of the code is closed, or there are commercial plugins that are very useful, and so forth.

With "2" the only way to get money is to either close part of the software,

Or, as in our case (x264), you keep everything open, but open source version is GPL, thus limiting its possible use in proprietary software packages, whereas the commercial version is not (despite them being line-for-line identical).

This only works if the project's license is copyleft, of course.

If the project's license is copyleft and copyright is clearly held by the project, not by contributors. That can be a problem.

That's what contributory license agreements are for: any project that plans to follow such a route needs to get all their developers to sign one in order to get the rights.

In my experience this was some effort, but not overwhelmingly so, IMO. This would probably be more difficult for a larger project, but other projects have done similar things (e.g. VLC's planned relicensing of libVLC to LGPL).

Reply on news.ycombinator.com