Asay the Alfrescan

I’m reading a research paper [PDF] by Nicholas Economides (NYU) and Evangelos Katsamakas (Fordham) called “Linux vs. Windows: A comparison of application and platform innovation incentives for open source and proprietary software platforms.” Long title, but the conclusion of the paper is relatively brief:

In our model, firms and developers invest to improve the quality of the platform or the application and expand the demand by users of these software products. When the operating system is proprietary, the platform provider and the application provider invest only in their own product to maximize their profit. When the operating system is open source, there is no platform provider firm, but the users invest in the platform to maximize their user surplus and their development reputation, which depends on the success of the platform measured by its adoption. (2)

Follow that? Well, I had to read it a few times through (academia tries so hard to keep its findings secret with obtuse language. So don’t feel bad. (Or maybe I’m just dense.)

Here’s the gist. When a platform (like Windows) is proprietary, only the vendor can/will invest in its innovation. No one else will derive financial benefit (or reputational benefit) from doing so. So, the product is as good (or bad) as the proprietary vendor makes it.

With an open source platform, the users of the system may have strong reputational incentives to develop it, potentially leading to much higher levels of involvement and innovation than any one company can generate. But, as the authors suggest, this finding is ambiguous, because the platform may not offer the reputational benefits (See page 15).

What is less ambiguous is the application providers’ incentive to help develop the platform, just as IBM, Oracle, Novell, Red Hat, HP, etc. have done with Linux:

The application provider for the open source operating system invests more than the application provider for the proprietary operating system, because the first has a larger marginal profit for all levels of investment. This is because the open source operating system is adopted by users for free, enabling the application provider to set a larger price and capture a larger profit than the application provider for the proprietary operating system.

Put bluntly, the price for Oracle/IBM/SugarCRM is much more attractive to end-users if it’s running on an open source platform, which gives these companies ample incentive to co-invest in its development.

This would just be idle academia if it hadn’t been shown to work in many instances, with the number (and importance) of these instances growing all the time. Linux. Apache. Eclipse. Xen. MySQL (SAP’s investment of money and resources, among others’). Etc. Open source gives third parties the means and the incentives to innovate on others’ platforms, be it an operating system, database, content management system, or whatever.

No proprietary platform can match that.

Leon Gommans (of the Holland Open Source Conference) sent me a link to a great site today: Ohloh. Ohloh estimates the value of open source software (measured in terms of lines of code and the cost it would take to pay someone to write that code - so, not the value one derives from it, but rather how much it would cost you to write it from scratch), highlights licenses used in a given project, and tracks developer and project activity over time.

It’s not a perfect tool, but it’s quite interesting. (I think Ohloh used a decent way to measure software value, but often it can be more expensive to pare down your code base than it is to “ramble” in your code. But I don’t have a better suggestion of how to do it.)

Here are a few sample projects I pulled:

• Mambo

• JBoss Portal
• SugarCRM
• Alfresco
• Liferay Portal
• Struts (The factoids on this one are interesting)

This is a great service and, as Leon noted to me, reiterates the fact that open source projects can’t lie. An open source project can claim something (the language it’s written in, the strength of its community, the number of outside developers, or whatever), but the code doesn’t lie. It’s all there, and Ohloh captures much of it.

Thanks for sharing, Leon!

That was the promise my Ban deodorant made to me today. It lied.

Consumer products often lie to us, or stretch the truth (also known as lying). We buy this toothbrush because it will give us “brighter, whiter teeth,” drink this drink because it will give us energy, or whatever.

One of the things I love about open source software is that it is lie-proof. I can say what I want about the product, hyping its benefits and obscuring its failings to convince you to use it. But at the end of the day, you can download it and immediately know if I’m lying.

To be frank, this can be frustrating. With proprietary software, you buy before you try. You write the check based on media, references, and a salesperson’s word that her product is as close to divinity as you’ll get on this earth. You rarely get to actually use the software in any meaningful way. It therefore matters a great deal how persuasive the salesperson is, and not nearly as much how good the software is.

Which is why the industry is rife with stories of enterprises buying software and then paying multiples over the purchase price to actually make the software work.

For open source companies, the software really does sell itself…to a point. That’s not to say that good salespeople aren’t important. They are. But they fill a different role in open source. They’re more about helping to demonstrate how to maximize value with the software, and less about how to maximize their commission from a bloated license price.

To the extent, then, that an open source salesperson exaggerates the benefits of her software, she hurts her company because open source companies only get paid for delivering constant value/service. If the customer never manages to get the exaggerated promise to materialize, their support contract will last the first year and then the customer will invest in other software. No lock-in beyond customer service.

Open source is a more honest way of doing business. It keeps you honest and customers happy. They get what they pay for, not empty hype. When you’re selling it, you sometimes wish they’d shorten the sales cycle even further by buying a little hype upfront, but I’m happy to trade a little instant person gratification for long-term customer satisfaction.

I actually thought Digium would never take venture funding. The company doesn’t need it ($10M+ in sales and profitable), but apparently David Skok of Matrix Partners gave Mark Spencer (founder and CEO of Digium) an offer he couldn’t refuse:

Make that $13.8 million of them.

Matrix is one of my very favorite venture firms: great people to work with (David Skok and Bob Lisbonne both count as two of the first three to five people I’d talk to if I were to start a company) and very intelligent about what they invest in. They’re choosy.

Why Digium? Well, David puts it best:

“This company has an incredible power to disrupt the dynamics of what has been a very staid and closed industry,” he said. Even with its free software base, he said, Digium is “one of the most profitable businesses I’ve come across anywhere in the venture world.”

That’s saying something. And it cuts against the arguments Dan Farber was raising in his latest post on open source businesses. (He has a nice response to mine here.)

This is a great investment - one that should pay off even better than JBoss did for Matrix, if only because JBoss has set the stage for many profitable exits to come.

Btw, here’s a picture of David and Mark Spencer at OSCON. Anyone watching the two at the conference knew that an investment was afoot:

Good luck to Mark as he continues to build a killer business!

Gary Edwards (Open Document Foundation) and I were talking yesterday, and he mentioned the NASCIO (National Association of State CIOs) Conference coming up. I checked out last year’s conference and found an interesting set of slides from an open source session they held.

From the slides, some useful data on why state governments are buying into open source. (Note: The survey was to CIO-level IT people within state governments. Pretty credible data, especially since NASCIO gets 350-450 senior government IT folks out to its annual conference, and restricts the survey (unless I’m reading the site wrong) to the most senior IT officials).

Anyway, why are state CIOs buying into open source? Well, for one thing, because it costs less. But also because it works better:

As for where they’re currently at in adoption the answer is hugely positive: not very far. Why is this positive? Because I’d rather be at 25% and growing than 99% and shrinking.

What’s holding it back? Again, the news is good, because it reveals, in the first place, a lack of understanding about how much the open source market has matured (support) and, in the second instance, a need for more capable IT staff. This will happen organically as the youth are being raised on open source. In 10 years, it will be Windows/SQL Server/etc. expertise that will be lacking, not Linux / MySQL / JBoss / SugarCRM / JasperSoft / Alfresco / Digium / etc. expertise. Microsoft will be the Buick driven by my grandmother (bless her!), and open source will be the Honda or Toyota that everyone drives because it’s cheaper, works better, never breaks, etc.

Why am I so optimistic on this open source future? Because the customer satisfaction it brings:

Time to call your state government and vote open source. Sounds like they’ll be happy to get that call.

Earlier this week I delivered a presentation at OSCON 2006 entitled “Making Sales While Making Friends: Lessons Learned from Open Source Businesses.” I’ve been involved with commercial open source since 1998, and have learned a lot over the years (including how to fail spectacularly and slightly more gracefully). I’m in the middle of a string of successes, though, and figured now was the time to pretend to know-it-all. You can view my OSCON 2006 presentation here. It was an extension of some JBoss analysis I did recently, as well as an attempt to pass on some of the lessons I’ve learned so that the next round of open source commercialization will avoid my mistakes.

My basic premise is that an open source business is hard work, and requires that entrepreneurs spend as much time thinking about the “second sale” as they do about the first sale. In the proprietary world, you sell a big upfront license and then promptly forget about the customer. In open source, however, every business model variant I’ve seen requires ongoing customer service to help ensure a “second sale” (i.e., renewal of an “Enterprise” license or support contract).

There is a range of ways to help secure a second sale, but the most popular of which (but still nascent) is the “network” offering. Hyperic offers the infrastructure to build such a network - others (including Red Hat, MySQL, and SugarCRM) have built their own. A network offers real value to the customer, above and beyond support, and should be on the shopping list of every open source company.

I argued that the type of sales model an open source company has should directly correlate with its market penetration…

…which is perhaps best measured by its downloads:

Regardless of the sales infrastructure (starting with inside sales, usually, and moving to direct sales over time), marketing is critical to success, because marketing improves conversion rates and builds deal size as brand value intersects with download rates:

I also suggested that startups be realistic about outside development assistance. The Sourceforge (and other) data doesn’t lie: you’re going to do the bulk of your core development work. You need to worry about building a user community. The development assistance will come, and it is significant, but don’t wait for someone else to build your product for you. (As I’ve written before, some projects - like SugarCRM - see a lot of partner-assisted development. In Alfresco’s case, nearly all of our outside development comes from our customers. Not sure as to the reason for the difference….)

Despite my incessant harping on Silicon Valley, I argue that you need to be where your market is, and today the paying open source market is overwhelmingly in the US (with Europe starting to catch up):

And, among other things, I revisited the idea of what it takes to make a successful open source project, commercial or otherwise:

There’s more to the presentation which you can see in the download above, but this was the baseline “gist” of it. I really enjoyed giving the presentation, and expect to give a revised version at OSBC 2007. See you then/there.

Computer Business Review has an interesting review of the United States Department of Defense report “Open Technology Development“. [PDF] If you haven’t read it, you need to take a look. It is one of the most clear-sighted documents on open source that I’ve yet read, and should banish CIO doubts as to the core benefits of open source: cost savings, security, speed of development, robustness of development, etc.

SCO and others have been crying ‘Foul’ on the US government’s increasing adoption of open source, suggesting (as Darl McBride writes here in his letter to the US Senate and House)

“I assert that open source software - available widely through the Internet - has the potential to provide our nation’s enemies or potential enemies with computing capabilities that are restricted by US law.”

Think that’s a bit silly? Try this one, from the CEO of Green Hills Software:

“Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software that will soon be incorporated into our most advanced defense systems.”

Apparently O’Dowd (Green Hills CEO) has never actually taken the time to learn how open source and, specifically, Linux, operates. But we’ll forgive his abject ignorance on the condition that someone pays his tuition to head back to school at some point. He needs it.

Anyway, back to the Department of Defense’s report. It has a treasure trove of insight, nicely counterbalancing the ignorance noted above:

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department.

Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems….

Software code has become central to the warfighter’s ability to conduct missions. If this shift is going to be an advantage, rather than an Achilles’ heel, DoD must pursue an active strategy to manage its software knowledge base and foster an internal culture of open interfaces, modularity and reuse. This entails a parallel shift in acquisitions methodologies and business process to facilitate discovery and re-use of software code across DoD.

The national security implications of open technology development (OTD) are clear: increased technological agility for warfighters, more robust and competitive options for program managers, and higher levels of accountability in the defense industrial base….

DoD needs to use open technology design and development methodologies to increase the speed at which military systems are delivered to the warfighter, and accelerate the development of new, adaptive capabilities that leverage DoDÂ?s massive investments in software infrastructure.

To be fair, the DoD is not talking about open source exclusively in this report. It is talking more broadly about open development:

In the private sector, changes in design methodologies for software development are enabling enormous gains in productivity and efficiency. Individuals and companies are able to leverage open technology platforms to rapidly deploy new solutions and capabilities to improve their competitive advantage. These open technology platforms may be open source or proprietary software applications with open standards and published interfaces that allow the rapid development of new capabilities by third parties without coordination agreements.

It’s the mash-up mentality, in some ways, that seems to appeal most to the DoD. But it’s not just about “Web 2.0″ thinking. It’s about how to make the DoD a participant in the wider software community, thereby saving development cycles and development dollars, as this fascinating excerpt indicates:

DoD has two competing interests:

1. Provide for the defense of the U.S., and;

2. Support and grow the U.S. industrial base, which provides materiel and systems so that DoD can accomplish its mission.

These trade-offs are well understood for physical goods and services, but not as well understood for digital ones. DoD can easily calculate the cost difference between developing or acquiring a physical good or service by simply comparing make or buy costs. There is however a fundamental difference between physical and digital products. Digital goods (software code, music, movies, etc.) once created can be copied perfectly with relative ease: limiting distribution enforces scarcity, but that scarcity is arbitrary and negotiated, rather than an innate property of the product. SoftwareÂ?s
ability to be replicated also means it can be incorporated into other software systems without Â?using upÂ? the original component, as one would with physical components.

The business model of purchasing physical goods and services has served DoD well in the past; but it falls short when applied to software acquisition. By treating DoD-developed software code as a physical good, DoD is limiting and restricting the ability of the market to compete for the provision of new and innovative solutions and capabilities. By enabling industry to leverage an open code development model, DoD would provide the market incentives to increase the agility and competitiveness of the industrial base.

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department. Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems.

DoD needs to evaluate the impact that locking into one set of proprietary standards or products may have to its ability to react and respond to adversaries and more importantly, to technological change that is accelerating regardless of military conflict. In order to remain competitive in a rapidly shifting technological landscape (including the disruptive technologies leveraged by our adversaries), DoDÂ?s software development and business processes must break out of the industrial-era acquisitions mold.

Amazing stuff. The DoD summarizes as follows, and shows a clear understanding of open source’s benefits:

To summarize: OSS and open source development methodologies are important to the National Security and National Interest of the U.S. for the following reasons:

• Enhances agility of IT industries to more rapidly adapt and change to user needed capabilities.

• Strengthens the industrial base by not protecting industry from competition. Makes industry more likely to compete on ideas and execution versus product lock-in.
• Adoption recognizes a change in our position with regard to balance of trade of IT.
• Enables DoD to secure the infrastructure and increase security by understanding what is actually in the source code of software installed in DoD networks.
• Rapidly respond to adversary actions as well as rapid changes in the technology industrial base.

Amen. Now if you’re a CIO tasked with saving money and resources for a large or small enterprise, wouldn’t it seem prudent to follow the lead of an organization tasked with saving taxpayers’ money and lives? Yeah. Me, too.

However you dress it up, at the end of the day open source is about support. It’s therefore critical that open source companies invest heavily in support.

How? JBoss provides the answer. (Here’s the layout of JBoss’ support offerings.)

Who do you get when you ping JBoss for support? You get a core engineer. At JBoss, engineers commit to spend 25% of their time supporting customers. (At Google, they commit to spending 20% of their time thinking up also-ran applications - ouch! I’d rather get the support engineer.) The head of support, then, is primarily responsible for corraling engineers to ensure they’re spending at least 25% of their time on customers - current, not future. They don’t hire low-end support people - they hire engineers who also do support.

This is an exceptional model (one that we’re trying to emulate). The benefits are obvious:

1. Customers don’t have to waste time with someone that can’t understand their issues. They quickly get to the very engineers who wrote the product.

2. JBoss (now Red Hat) benefits because customers want to buy from the source of the code.
3. JBoss engineers benefit because they get to hear from real people with real problems with their software. Engineers can fall into a “My code has no problems” mentality. Talking with customers helps them see how it (mal)functions in the real world, helping them develop better products.

Again, whether you’re using an “on-ramp” (SugarCRM) model or a Red Hat model or whatever, support is the core of an open source company. JBoss shows how to do it right.

Hell is feeling chilly today. Microsoft, long known to have the mark of the beast written in its forehead, has gone and done something that makes it feel like a Leave It to Beaver rerun: it has opened up Office file formats. (Aw, shucks!)

Well, not directly, but at midnight PDT last night, Microsoft released on Sourceforgea tool - the Open XML Translator - that translates Microsoft Office files into the Open Document Format, and vice versa. Few have been clamoring for this, but Microsoft was bumping into governments that had to offer ODF compatibility, even if just one citizen wanted it. (You can try it out here.)

Big news? I think so (though Microsoft does not - nary a word about the move on its news/press release page). It means that file-level lock-in can be made obsolete (though it does require people to actually use the tool - more on that below). It also demonstrates a real commitment on Microsoft’s part to participate in the open source community: the Open XML Translator is being housed on Sourceforge (answering critics who thought its CodePlex a threat to Sourceforge), and is licensed with a BSD (not Microsoft) license. BSD is the most permissive of all licenses (and, hence, the least capitalistic).

Microsoft, in making this move, must have recognized that it would cannibalize little to none of its Office sales, because almost no one is going to bother to make the file conversions - having the ability to do so will be enough. The company also recognized that it now has a far bigger lock-in threat than Office formats ever aspired to be: Sharepoint. With Sharepoint, Microsoft can lock in a company regardless of the file formats that company uses - .ODF, .XLS, .DOC, .PDF, .ETC. Because Sharepoint creates a closed network of documents - it is lock-in at the network/corporate level, and is far more pernicious than Office could hope to be.

I assume this will change the world very little. It will, however, make it much easier for my company, Alfresco, to ensure 100% file compatibility when we do document conversions within our Enterprise Content Management system. I’m sure we won’t be alone in taking advantage of the BSD license on Open XML Translator - it should open up a wide range of opportunities for companies in the content business.

I was on a customer call with Kevin Cochrane today and a customer prospect. The prospect wanted to know how big Alfresco’s development staff is, which we were happy to tell him (open source companies tend not to keep silly secrets): 15. (Not everyone is on the site, for some reason, both developers and non-developers, but whatever.)

“15? Isn’t that small?”

Kevin’s answer was classic. In his experience at Interwoven (similar to mine at Lineo and even Novell), the vast majority of “developers” within a company are not core developers at all. They’re people writing drivers, doing QA, etc. In an open source company (just as in an open source project), the core development team tends not to scale well beyond 15-25 people. As noted in the link above for open source projects, the vast amount of code production (83% in terms of Linux, Apache, etc.) is done by ~15 people. Very few.

One of the exciting things about an open source company is that you take advantage of highly leveraged development, where the drivers, localization, etc. is done by the community, not your core development team. This means open source companies can spend proportionately less on development while simultaneously investing a lot more in core development.

Net result for the customer: better products, both because the core development team is innovating faster, better, longer, and the “peripheral” development is managed by a development community that reflects the diversity of an industry’s requirements. So, no one at Alfresco speaks Italian, but we have great Italian language support because our partners and customers speak Italian. Ditto for Japanese, Brazilian Portugese, etc. Our community shapes Alfresco in its image, while we focus on the core Alfresco platform. Everyone wins.

Except our competitors, of course. Or SugarCRM’s. Or Red Hat’s. Etc. Their competitors lose. They just can’t keep up with lower sales and marketing costs 1, coupled with lower development costs (and higher development investments). Yes, it’s unfair. But the proprietary vendors will get over it. Or they’ll come work for us.

1 NOTE: See the link for more information on open source sales and marketing costs. One thing I don’t talk about in the other entry, however, is that open source sales teams necessary to close a deal - even large deals - tend to be much smaller than in the proprietary world. So, sales costs truly are smaller, even over time.