Asay the Alfrescan

These past two weeks have been fascinating. Frustrating, but fascinating. Frustrating, because people have seemingly been duped by Oracle’s and Microsoft’s supposedly good intentions (these people have short memories). But fascinating as I watch open source come center stage in the software industry.

I’ve learned a great deal since I first got involved with open source in 1998. Lessons about sales, about trying to hide a poor product behind open source distribution (far too many vendors continue to do this…), about “pure” support models and their viability, among other things.

But one lesson stands out above them all, and was first related to me by a good friend at Red Hat:

Customers are open source’s only true friends.

A bit forlorn? Well, it might have seemed so before, until Red Hat’s top partner, Oracle, stabbed it in the back. Or until its top Linux competitor - and ally in the open source fight - Novell, sold its integrity to Microsoft.

If Red Hat can’t count on its partners to…partner, or its competitors to…compete, then on whom can it count?

Its customers. The companies that continue to rate it #1 in value.

If you’re an open source vendor, you need to understand that Red Hat isn’t alone in this. Your customers are the only ones who truly appreciate the value you can bring through open source. You may want to rely on a big, proprietary sugar daddy to help you get to market. By all means, do so. But if these past two weeks teach us anything, it’s that it’s critical to hedge our bets.

Open source vendors are a clear and present danger to all proprietary software companies. Open source vendors have no long-term friends among this Proprietary Bloc. Because, at the end of the day, open source’s lower prices and greater access are a direct threat to the license revenues and maintenance streams of the Proprietary Bloc.

Again, this is not to say that open source companies shouldn’t partner with proprietary vendors. Of course they should, as this will often lead to greater customer value. But they shouldn’t do so with a Pollyanna hope that the proprietary vendor is going to love them for demonstrating that software can be delivered with higher quality, lower prices, and a tighter alignment of vendor/customer interests through open source than it ever was with a bloated, customer-unfriendly license model.

Focus on the customer. Partners and competitors will come and go. Open source customers will stay true. Their businesses depend on it.

Dries Buytaert, lead developer on Drupal, has written an insightful post on the difference between forking a project and different distributions of that project. As he notes, the differences can be subtle, but ultimately come down to the intentions behind the divergence, revealed in how much the fork/distribution relies on the original project’s foundation for future development.

The distinction is critical in light of Oracle’s fork of Red Hat Enterprise Linux: customers that buy into Oracle’s support are effectively buying into a fork, and one that Oracle is ill-equipped to support.

But the distinction plays out every day in a myriad of different projects, and occasionally turns into a full-fledged fork, which tends to benefit no one (which is why it rarely happens in the community-minded open source world. Dries writes of Drupal:

It is important that Drupal distributions collaborate, and not compete. To do so, we have to provide Drupal distributions an environment that encourages collaboration, and that allows for specialization (such as custom documentation and support) without introducing incompatibilities that drive competition.

The good news is that we know how to do this. We’ve been through this already with CivicSpace (previously called “DeanSpace”), a Drupal distribution for online campaign management and grassroots activism. They were quick to realize that the success of the CivicSpace distribution depends on the success Drupal core, and vice versa. The decided they shouldn’t fork core development. Instead, CivicSpace decided to do all its development on the drupal.org infrastructure, to synchronize releases, to submit all patches upstream, to centralize bug reports, and to share documentation where possible. Collaboration, not competition.

The bad news is that can be hard work. People will find that creating a distribution is fun and easy, but that being a responsible maintainer might be a lot less fun. Who wants to track changes, write documentation, maintain modules, provide upgrade paths, manage releases and provide support for years to come?

In short, distributions are fine because they add value to the core. Forks are bad because they splinter communities and thereby fragment value, attenuating it until the point that either the fork dies or the originating project dies.

For this reason, I agree with Dries. What’s true of Drupal is true of other open source communities. He writes:

As a community we should disapprove Drupal distributions that do not intend to collaborate, that have no signs of long term commitment, or that risk locking people in.

Amen, Dries.

You want to know what keeps Steve Ballmer up at night? Apparently, not specific competitors, but rather competitive industry trends that strike at the core of Microsoft’s software license business model: open source, advertising, and software-under-the-guise-of-hardware. (Thanks to Brady for calling out the BW article.)

Ballmer says:

Who are Microsoft’s top competitors?

Guys who can touch us in multiple places probably matter more than guys who can touch us in any one place. And actually we don’t really have our big competition from any one company. Any one company, we know how to compete with. It’s alternate business models that we will have to embrace or compete well with. You give me any enterprise software company, O.K., and I’ll say c’mon. We know how to go do that. We do do that. And we’re really pretty good at it. We haven’t gotten any worse at it. Boom. Boom. Boom. We know how to keep coming.

[Take open source.] Open source is not a new technology area. It was a new business model. In the last three or four years, we have competed very well by extending our value. Open source never goes away as a business model or competitor. We have learned how to compete with open source, and we will compete with it for the rest of time. But competing with open source will have to be something that’s burned bright on the foreheads of our senior people.

The second big competitive force is advertising as a business model. Typically, people just want to reduce that to Google, and if you want to do that, you can. But it’s do we embrace advertising fully enough as a business model? Because at the end of the day, anybody who comes at you with a cheaper-to-the-customer proposition, you got to worry about. And advertising looks cheaper to a consumer than something you pay for.

In the case of open source, we couldn’t adopt the business model. We adopted a competitive approach that so far has worked very well. In the advertising case, we can embrace that model. We don’t have to sit here and say it’s that bad.

A third model I could sit here and write down on this list is that there are cases where software gets monetized through hardware. That’s what an iPod is. iPod is a software thing. You just happen to collect the money on the hardware. You could say in China and India, it’s unclear whether classic software will get paid for as much as advertising, hardware, subscriptions, etc.

So our ability to embrace and benefit from or compete with new business models—and I would say ad-funded and open source, more than this hardware thing—is more the way to categorize the key competitive dynamic for us.

Fascinating stuff, and I’d encourage you to read the rest of the interview, too.

This isn’t revolutionary stuff (Clay Christensen has been talking about how to disrupt an industry for some time), but it’s interesting to hear the CEO of the world’s largest software company candidly explaining how to beat Microsoft. As with open source code, just because you have “the answer” doesn’t make it any easier to crack the code.

To disrupt a Microsoft product you have to cut off its traditional air supply. Open source is disruptive to Microsoft because it a) removes the one-size-fits-all approach that Microsoft imposes and b) the entry cost is $0. Microsoft knows how to disrupt with “free” (remember IE?), but it has yet to learn how to compete with someone else undercutting its prices by 100%.

Over the long haul, however, it’s going to be modifiability that beats Microsoft. This will sound odd to many, because the common industry wisdom is that no one wants to modify anything. We just want to passively consume software. My experience at Alfresco and Lineo, however, has been the complete inverse of this received wisdom. Many users want their Firefox customized to them. Many enterprises want their ECM customized to them. Etc.

Microsoft has been good about enabling a robust partner ecosystem to extend its products. The question will be whether it can allow its customers, non-customers, and non-partners to do the same. I don’t think it can, and I think that matters.

At Gartner’s Application Development Summit, Gartner analysts Dale Veccio and Matt Hoyle opined on the present and future of enterprise application development, as reported by DevSource. Their keynote focused on four themes: the new application development lifecycle (with an emphasis on delivering applications better and faster - imagine that!), project and portfolio management, “frontier” application development, and project management and governance.

Related to that last them, I found this particular commentary revealing:

“The future of application development is not about programmer productivity,” said Hoyle during the keynote presentation, “but in assembling functionality from components.” While programming will not go away, he stressed, programming has decreasing importance in delivering excellence. “Assembling, buying, and extracting is an increasing part of what you need to do,” he said. To be more agile and responsive, application development managers have to manipulate, orchestrate, and compose new business processes, using resources available from outside partners, third-party applications, Web services, and existing code components. Veccio asked, “Why would you ever code an app from scratch again? Why would you need to?”

Reading between the lines, or reading into his comments my own bias, this sounds like a clarion call to use more open source software. Yes, application developers can build from scratch as they’ve often done in the past. But why? If you need a best-in-class content repository, why wouldn’t you use Alfresco’s? Need to embed a database that looks/smells/acts like Oracle, but isn’t? Use EnterpriseDB’s version of PostgreSQL. Want web conferencing functionality but don’t want the headache (product-based, license-based, and cost-based) of WebEx? Use DimDim. And so on.

There’s so much exceptional open source software out there, available at a fraction of the cost of self-development or proprietary software…why would you ever want to do it yourself again?

We’ve known for years that upwards of 70% of web sites use Apache to power their sites. We also know that much of MySQL’s thriving business comes from “Web 2.0″ companies - the web runs MySQL (and a heck of a lot of Linux). What has been less clear is how much of the web that we see is managed by open source web content management systems.

Dries Buytaert, lead on the Drupal Project (a leading web content management system), sent me the results of an interesting, 5000-web developer survey that sheds light on the question. The survey was conducted from June 2006 to July 2006, and released by as the “2006 State of Web Development” report by SitePoint Pty Ltd. and Ektron, Inc. This is must-read material for anyone in the WCM space, but also interesting for those tracking the rise of open source.

The results? A huge swath of the web is managed by open source, with the vast majority of the remainder well-positioned to be consumed by open source.

Also in the report: LAMP and Microsoft own the web. They account for the vast majority of server platforms that web developers use. This is one reason that Alfresco has a web scripting language interface to a Java backbone - we can be coded quite easily in Ruby, Python, PHP, or Perl, which is a requirement if you want to help power the web. The “P” (and now Ruby) is clearly A Very Big Deal. It’s why Zend has such a bright future, for example.

Also of note in the report is how pervasive collaboration-type functionality is becoming. Ajax is being planned by ~47% of web developers, with blogs (38%), podcasts (25%), wikis (20%), syndication (36%), and other features increasingly incorporated into websites.

Much of this functionality will be driven by open source (and/or open standards) -based software. Given how much of our lives is moving to the web, it’s just one more indication that open source, not proprietary software, will dominate the next millenium. Sorry, proprietary guys! At least you had a fun ride while it lasted.

Many thanks, Dries, for sharing the link to the report with me!

I was reading a research paper [PDF] last night by Martin Michlmayr (University of Melbourne) entitled “Software Process Maturity and the Success of Free Software Projects.” The paper addresses the question of “whether the maturity of particular software processes differs in successful and unsuccessful projects” (1).

While the paper offers little in the way of hard conclusions, it does make some interesting observations.

• Version Control Tools.
  

  Version control tools, such as CVS in the case of projects hosted on SourceForge, are used more widely in successful than in unsuccessful projects. Furthermore, a higher percentage of version control repositories are available publicly. In free software projects, CVS and similar tools play important roles related to coordination. Having a private version control repository limits the access of prospective contributors. On the other hand, a publicly available CVS repository allows contributors to monitor exactly what other people are working on. This allows multiple people to work together efficiently in a distributed way. In a similar way to defect tracking systems, public version control systems may attract more volunteers since users see what needs to be done and how they can get involved.

• Mailing lists. 80% of successful projects use mailing list archives, compared to 50% of unsuccessful projects.
  

  In both, version control tools and mailing lists, it is not clear from the present findings whether a successful project requires these types of infrastructure to flourish, or whether the implementation of the infrastructure has attracted more volunteers and so led to more success. Our assumption is that there is no clear causality and that both affect each other.

  Still, it would appear that mailing lists are important for lowering the “cost” of outside contributors getting involved with a project, as it serves as a form of documentation. (I’ve talked here about the importance of documentation.)

• Documentation. Interestingly, documentation wasn’t found to definitively impact a project one way or another:
  

  it can be argued that user documentation is an important factor in free software projects. However, this factor alone does not determine success. Developer documentation, on the other hand, is not very common in free software projects. A reason for this might be that prospective developers find most answers to their questions from other sources, such as mailing list archives or the source code.

  Still, the author doesn’t analyze code quality of the projects with/without extensive documentation, as well as other factors. My bet (based on experience) is still that documentation is outcome-determinative in open source projects.

• Systematic Testing.
  

  The analysis of processes involving testing shows that successful projects make more
  use of release candidates and defect tracking systems than unsuccessful projects. There is no difference in the presence of automated test suites. The availability of release candidates has been taken as an indication of a well defined release plan. While it would be revealing to qualitatively study and compare the release strategies of different projects, the present findings suggest that a clear release strategy coupled with testing contributes to the success of a project.

  Let the developers know where you’re going, and when you’ll get there. This makes it easier for them to find the time and inclination to help.

Not a lot of big conclusions in the paper, but it does point to one general theme: successful projects are permeable. They make it easy (or relatively so) to contribute and use the software. Less successful projects horde information and so require larger investments of time in order to use or contribute to the project.

So, if you’re thinking of starting a project, or wanting to improve use of an existing project, try improving access to your CVS (or whatever you use), use of mailing lists, and follow a well-defined release plan. Oh, and document everything. It’s boring work, but it’s critical.

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.

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.

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.

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.