Asay the Alfrescan

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.