Showing posts with label services. Show all posts
Showing posts with label services. Show all posts

10 September 2007

Writing the Book on Open Documentation

One of the things I really like about Matt Asay's blog is its total candour, which extends to handing out what most companies would regard as confidential business information:

the vast majority of our deals are fed by two direct sources: those who read our documentation and those who actually download and try our Enterprise code. Now, we also know that most of these people first start with our Community code (and often evaluate it for months, reading documentation and visiting our website in the meantime).

What does this mean? It means that if our demand generation software is telling us that someone has both read documentation and evaluated Enterprise, the odds of them buying support from Alfresco are huge. We want to be calling that prospect immediately.

But it also means that documentation is a huge opportunity for open-source companies to drive sales. Documentation is often treated as the shabby cousin of software development, but it is really the essential link between development and dollars. It's hard to motivate good documentation.

The other lesson I'd draw from this is that open source (and selling it) is far less about the code than you might think. Similarly, I'd say that open content, for example, is not just about the raw words, images or the sounds, but very much the "documentation" - that is, the packaging/service - that you provide around it, too.

15 August 2007

O'Reilly? I Think Not

Once again, Matt gets it, and Tim doesn't:

"I will predict that virtually every open source company (including Red Hat) will eventually be acquired by a big proprietary software company."

Thus spake Tim O'Reilly in the comments to one of his other posts. Tim believes that open source, at least as defined by open-source licensing, has a short shelf-life that will be consumed by Web 2.0 (i.e., web companies hijacking open-source software to deliver proprietary web services) or by traditional proprietary software vendors.

In other words, why don't I just give up, sell out, and go home? I guess I would if I thought that Tim were right. He's not, not in this instance.

There's something more fundamental going on here than "Proprietary software meets open source. Proprietary software decides to commandeer open source. Open source proves to be a nice lapdog to proprietary software." I actually believe that open source, not proprietary software, is the natural state of the industry, and that Tim's proprietary world is anomalous.

I particularly liked this distinction between the service aspects of software, and the attempts to view it as an instantiation of various intellectual monopolies:

Suddenly, the license matters more, not less, because it is the license that ensures the conversation focuses on the right topic - service - rather than on inane jabberings that only vendors care about. You know, like intellectual property.

And there's another crucial reason why proprietary software companies can't just open their chequebooks and acquire those pesky open source upstarts. Unlike companies who seem to think that they are co-extensive with the intellectual monopolies they foist on customers, open source outfits know they are defined by the high-quality people - both employees and those out in the community - that code for the customers.

For example, one reason people take out subscriptions to Red Hat's offerings is that they get to stand in line for the use of Alan Cox's brain. Imagine, now, that proprietary company X "buys" Red Hat: well, what exactly does it buy? Certainly not Alan Cox's brain, which will leave with him (one hopes) when he moves immediately to another open source company (or just hacks away in Wales for pleasure). Sure, the purchaser will have all kinds of impressive legal documents spelling out what it "owns" - but precious little to offer customers anymore, who are likely to follow wherever Alan Cox and his ilk go.

29 January 2007

At Your Service

It is no coincidence that services lie at the heart of companies based around open source:

In 2006, the share of the service sector in the global employment progressed from 39.5 per cent to 40 per cent and, for the first time, overtook the share of agriculture that decreased from 39.7 per cent to 38.7 per cent. The industry sector represented 21.3 per cent of total employment.

(Via Technocrat.)

30 July 2006

Open Source, At Your Service

So far, the best answer to How can open source companies make money? seems to be that of providing services - typically training, support and general consultancy. There's another approach, involving dual licensing, but this is more problematic in some ways, and there's also evidence that it may only be a transitional approach on the way to a full service model.

Against this background, Irving Wladawsky-Berger has an interesting post on his blog about services, beginning with this observation:

If you look at IBM's business last year, services revenues were roughly 55%, while systems (hardware) and software revenues were around 25% and 20% respectively. But services constituted around one-third of the company's profit, for a very simple reason. Systems and software products leverage technology assets and apply engineering principles to improve quality, scale-up capacity, and achieve higher productivity and profit margins. Services, on the other hand, have historically been significantly more labor-based, less prone to economies of scale, subject to higher quality variations, and generally less productive and profitable.

Services - and analyses of them - will clearly be moving to the foreground in years to come, and not just in open source. The latter will, however, be a trailblazer in this respect as in many others. Another reason for those outside the world of free software to pay close attention to it.

18 July 2006

Trouble at 't Mill

The World Wide Web Consortium (W3C) is the sticky stuff that holds the Web together; without it, the whole caboodle would slowly come unstuck, fraying into lots of proprietary strands.

So this kind of posting, which seems to indicate problems at the heart of the W3C, is deeply worrying:

I believe for our society to progress it's essential that our culture, our knowledge, and our society itself are as accessible as possible to everyone; web standards are how we choose to achieve this on the World Wide Web, and for us to communicate, especially if we have special needs or novel ideas about information access, it depends on compliance to web standards. With this in mind I became interested in assuring standards compliance on the Web and involved in the development of tools meant to help in this respect at the World Wide Web Consortium seven years ago.

I now have to discontinue my participation in this area at the W3C and would like to explain how the World Wide Web Consortium failed to provide what I think would have been and still is necessary to advance the tools and services to an acceptable level, which will explain why I am leaving now.

(Via Slashdot.)