Subject: Re: Nessus 3.0's failed community
From: Brian Behlendorf <brian@collab.net>
Date: Wed, 30 Nov 2005 13:53:17 -0800 (PST)

On Wed, 30 Nov 2005, Stephen J. Turnbull wrote:
> FWIW, I suspect that an important factor in the Nessus case is that
> Nessus is a focused, specialized application, not a platform.  With a
> platform like GNU/Linux, on the community-origin side, or Eclipse, on
> the corporate-sponsored side, everybody can have it their way by
> contributing the module they want most.  Along the way they'll note
> and help fix bugs in the platform.  And because a platform is such a
> broad thing, there are plenty of shallow bugs, and of course "plug-in
> architecture" means most extensions have no more depth than the sheet
> of paper you print the API on.

I understood Nessus to be a conglomeration of a bunch of different exploit 
tests, actually, so it sounds like both a framework and a collection. 
Should have been ideal for parallelizing effort and the same platform 
advantage you mention.  I think the reason why platform-ish projects have 
been more successful to date is that it doesn't encroach on the 
proprietary business of apps built upon that platform; i.e. Apple can 
rationalize its investment in Darwin by saying it helps ease Aqua (their 
proprietary GUI layer) development.

> But in the case of a focused application, the better it gets, the
> harder the bugs are, and the more satisfied the majority of community
> users are.  They are necessarily going to lose interest in working on
> a "good-enough" project and lag in the competence to do so.  The
> corporate interest isn't in fixing the UI warts that bug the
> relatively casual "community users", it's in "big wins" that only the
> (usually corporate) industrial strength users are willing to pay for.
> Thus, corporate and community interests diverge.

Which seems strange - there are always new security holes discovered and 
thus always new tests to come up with and run.  Nessus 3.0, the non-free 
version, also claims significant speedups and new features, which I assume 
someone figured there would be a market for (i.e. that Nessus 2.2 wasn't 
"good enough".)  Rather than close up everything, Nessus could have 
bifurcated and said the framework and community-provided tests would 
always be free, but Nessus Inc had some proprietary extra tests that 
provided extra protection, or something.

But yeah, in this case, the real question is - were there no contributors 
due to lack of interest or perception of perfection (in which case, even a 
support/services oriented business model would be doomed!) or was it 
because those who had an inkling to get involved faced a closed door when 
it came to the way Nessus was developed.

On Wed, 30 Nov 2005, Larry M. Augustin wrote:
> I wasn't referring to the end user's benefits, but rather to the competitive
> benefits that a company like Nessus might enjoy by releasing their product
> Open Source.

So, it'll be interesting to see whether their move from open to closed 
negatively affects their position in the market in this way.  Will it be 
the case that companies will continue to download Nessus 2.x, enjoy it but 
want support, see that Nessus 3.0 has more features and is faster but 
requires commercial licensing, and pay it?  I hope not - that would 
encourage companies to follow that approach, where once an open source 
project reaches a critical userbase and popular acclaim it's 
re-proprietarized under the same name.  Ick.

More generally, low-cost or free "try before you buy" has been around the 
industry forever, whether as shareware, limited-time or -user demoware, 
beta programs, etc.  But they all had the premise of licensing fees when 
you decide you want to "get real".  If the revenue story is only around 
licensing, the only unfair advantage a company like Nessus has over other 
competitors who can use Nessus's code to provide those same services is 
some claim that "we wrote the code/lead the community, therefore we can 
provide the best services".  It's not a compelling sale.  It allows the 
competitors to claim "they might have written the code, but we've invested 
in providing the best services around their code".

The fact you cited in your essay 
(http://sandhill.com/opinion/editorial.php?id=54) that 82% of software 
licensing fees goes to sales and marketing was great - that's a fact that 
just sounds insane and likely to stoke up a storming of the Bastille. 
But then you suggest that with OSS, that S&M number can drop, and you can 
focus instead on much more profitable maintenance contracts.  The problem 
with that analysis is that the nature of maint contracts between these two 
different sales models is very different - proprietary software vendors 
are the exclusive providers of those kinds of deals (or can delegate to 
others of their choosing), whereas anyone can sell support contracts for 
open source software.  So a proprietary software vendor will happily sell 
a license to the product for below its total cost in order to acquire the 
more lucrative maintenance contracts, because those maint contracts are 
still a very defensible business.  This is the essence of the software 
rental model, whether ASP like Salesforce or CollabNet, or a recurring fee 
even for shrinkwrapped product - license fees turned into maint fees, with 
product upgrades just a part of maint.  An open source vendor, though, is 
forced to rely upon maint contracts or other services for revenue, and in 
a much more competitive market.

> The discussion seemed to be focusing around community contributions to the
> code.  I don't see that as the main benefit in many high-profile Open Source
> businesses today.  To further clarify, my measure of "benefit" is to place
> the P&L of the Open Source business side-by-side with the P&L of the
> proprietary software business and look for some inherent advantage for the
> Open Source business.  For example, lower development costs in the Open
> Source business could mean lower total expenses allowing the Open Source
> company to charge less to customers and undercut the competition on price.

Except that the competition can use your code without making the same (or 
any) investment.  The only defense at that point is brand - the same brand 
for the company and the community, and a clear "ownership" of the 
community by one company, which would negatively impact the ability to 
grow it into a thriving multistakeholder community.  Or, you create a 
separate brand - Covalent and Apache, RedHat and Fedora, etc.  As an open 
source developer I'd much rather see the latter.  As an invester, the 
former appears to be the only way I get S&M leverage for the investment 
made in launching the open source project and making the free bits useful.

Which is better in the long term?  My gut tells me that a separate brand 
is better, and reducing your overhead (the cost of developing the free 
bits you give away) by seeking as much co-operation on the project as you 
can.  Watch, for example, as more and more Linux distribution companies 
ditch their own distros and become service providers around Debian or 
Ubuntu (with private-label branding, perhaps).  Scale can still trump; for 
example, I'm sure Marten doesn't stay up nights worried that Postgres's 
flatter community will present a threat to MySQL.  Anytime soon, at least.

But it's an interesting debate.

> If Nessus was approaching the community assuming they were going to get huge
> community contributions to the core code, and that was going to be the major
> benefit in being Open Source, then I would argue that Nessus' problem might
> have been that they were looking in the wrong place for the benefits to
> their business.
>
> Maybe what the Nessus failure may be telling us is that Open Source business
> models that rely primarily on benefits to the company in the form of lower
> development costs are not viable.  The benefit has to be more than that.

That's only a valid conclusion to make *if* we can show that Nessus was 
sufficiently open with their development processes, where their engineers 
used the community tools (mailing lists, bug trackers, code repositories, 
etc) and made development decisions as they would if they didn't work at 
the same company.  I would argue that they would have seen much 
more contribution if they had been, contribution that may have allowed 
them to spend freed-up resources someplace else building something 
defensible.

I would agree with a blanket statement that said that no company should 
anticipate major community contributions without putting an open dev 
infrastructure and open dev mindset in place.

> I'm going to repeat that because I've been rather long-winded here and it's
> my major point.  Lower development costs are not going to make up the
> difference.  You need to look at other expense lines to make the numbers
> work.  In particular, proprietary software companies spend a lot more on
> sales & marketing than they spend on development.  As a result there's a lot
> of opportunity to make a difference there.  If you can cut sales & marketing
> costs relative to your proprietary competition, then you can create big
> business model advantages.

I'll agree with the idea that lowering marketing & sales costs would do a 
lot of good.  The "standard" model says an enterprise software company 
should spend no more than 1/4 of their expenses on software development, 
1/10th on overhead, and everything else on S&M - a figure I could never 
accept.  But proprietary competition isn't the only kind of competition a 
company should be preparing for; especially with all the VC interest and 
with source code you're legally allowed to copy without fee and release 
derivative works from, you will have other open source competitors.  A 
race to the bottom during the last boom is what gave us 9 different online 
pet food stores, with some of them offering free shipping via Fedex for 
50-lb bags of dog food.  Software isn't dog food, but the point remains 
that building a defensible business model should still be the point.

 	Brian