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.

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.

Interestingly, IT dollars continue to rise, even as overall company revenues fell from 2005 to 2006:

As for where those dollars are going, despite all the hype that licenses don’t matter (because the real costs are in implementation), the numbers don’t bear that hype out. The numbers say, “Enterprises are wasting money on licenses.”

The license cost savings open source delivers (as compared, say, to Microsoft), however, would be negated if open source implementations cost more (in fact, they cost less or at least give the CIO choice as to how she spends those dollars) or if open source required more IT personnel (clearly the biggest IT cost). But experience proves otherwise, as The Robert Frances Group has written.

Besides, as The Christian Science Monitor and others have found, open source makes those IT personnel costs stretch farther, deliver more innovation, etc. Open source makes IT dollars work for the enterprise, and not for the vendor.

So, http://blogs.alfresco.com/asay/2006/10/12/microsofts-top-competitors/ 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.

Our startup honestly wanted to use OSS products. We do not want to spend time for any OSS bug fixing so our main requirement was -official support for all OSS products-. We thought were prepared to pay the price for OSS products, but then we got a price sticker shock….After all, we have decided that the survival of our business is more important for us then ‘do-good’ ideas. Except for that embedded Linux (slated for WinCE or VxWorks substitution), we are not OSS shop anymore.

Taking the author at his word - that commercial open source is, in fact, expensive (has he tried the alternatives?) - I think he’s asking the wrong question. Given that in his world the open source alternatives are actually better than their proprietary counterparts, his question really should be, “Why isn’t it more expensive?”

It surprises me that some people persist in wanting something for nothing, or next to nothing. Open source is about a superior software development and distribution methodology. It really has nothing to do with cost.

Today, it’s much cheaper. SugarCRM? A fraction of the cost of Salesforce.com, Siebel, etc. MySQL? Pennies on the Oracle dollar.

But maybe not forever. If in five years MySQL ends up being more expensive than Oracle (not sure how Marten and crew could find ways to jack up the price that much, but let’s assume he’s very creative , it won’t be for any other reason than the market will bear that price. And why would the market bear such price inflation?

Because it’s better software.

So, to the author of the article above, let me suggest that his projected switch to VxWorks or WinCE may get him exactly what he pays for:

Less.

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?

Zack cites Gartner’s Donald Feinberg:

Overall, Gartner is predicting that the worldwide DBMS market is around $14 billion and will continue to grow by nearly 7% per year. If this was a new market, it would not be a very impressive growth rate, but for a market of this size, it’s huge. And there can be lots of movement within the market. We are at the start of a new era where migration to open source technology is going to fuel the DBMS market. That includes migration away from Unix to Linux and from closed source to open source.

A few key findings from Gartner / IDC research:

• By 2008, open source databases will be used by more than 70% of IT organizations [Asay note: I’d actually be surprised if the number isn’t already closer to 100%. There’s a lot of open source database usage that isn’t registered by the CIO or whomever it is that talks with Gartner/other analysts.]

• By 2008, MySQL will be a serious choice for mission critical applications [Asay note: See below.]
• 56% of companies surveyed plan to switch to Linux as a DBMS platform
• Linux will surpass Unix as the leading DBMS platform within the next 3 years, even for the most demanding database applications
• 40% of surveyed companies are planning to replace proprietary DBMS with open source
• 49% of respondents have MySQL in deployment with 17% planning to deploy

This is impressive, despite the fact that the “Big Boys” still control 92% of the market, as Gartner reported earlier this year:

And it’s still funny to me that MySQL isn’t considered “mission critical.” It would be hard to find more demanding applications than Google, Yahoo!, Orbitz, etc. They all run MySQL. Lots of MySQL. Even Oracle runs MySQL.

Here’s a thought: Oracle is quickly building and buying its way into the center of the enterprise software ecosystem, using the database as the hub for all the enterprise application “spokes” it’s building/acquiring (CRM, ERP, ECM, etc.). Don’t you think that MySQL is well-positioned to do the same, except with open source applications?

Hmm….

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!

You are to be in all things regulated and governed…by fact. We hope to have, before long, a board of fact, composed of commissioners of fact, who will force the people to be a people of fact, and of nothing but fact. You must discard the word Fancy altogether. You have nothing to do with it. You are not to have, in any object of use or ornament, what would be a contradiction in fact. You don’t walk upon flowers in fact; you cannot be allowed to walk upon flowers in carpets. You don’t find that foreign birds and butterflies come and perch upon your crockery; you cannot be permitted to paint foreign birds and butterflies upon your crockery. You never meet with quadrupeds going up and down walls; you must not have quadrupeds represented upon walls….This is the new discovery. This is fact. This is taste. (17)

Such was Mr. McChoakumchild’s doctrine in Mr. Gradgrind’s model school, as described by Charles Dickens in his masterful Hard Times.

Reading these words on my flight home to London, I couldn’t help but laugh. First, Charles Dickens is one of the five funniest people to have ever walked this earth. Second, because he actually captured much of the feeling that goes into proprietary software.

It is now established as Fact that enterprises don’t want to modify source code. They prefer to be mute consumers of others’ IP, chewing the cud that comes their way. No room for Fancy. For participating in the code to change its present or future direction. This is unassailable Truth.

Except that it’s not. True, that is. I used to think it was true, but that open source mattered, anyway, because the option of choice proved a useful surrogate for the exercise of choice. (I might not choose to view and modify source code, but the fact that you could would tend to improve the initial effort that went into the code, among other things.) I still think this is true.

But it’s not as all-encompassing as I had thought. Over the past ten months or so with Alfresco, it has surprised me again and again (I’m a slow learner) at how much our customers want to modify source code. Arguably, this is a short-term, anomalous condition because we’re dealing with early adopters. We count several of the world’s top-10 financial institutions as our customers, among others - the very type of customer that does want to actively manage code, and not passively accept off-the-shelf code. The kind that believes IT does matter.

But even among those that don’t want to grime up their hands with co-development of our software, it’s surprising how many want to play a strong, participatory role in our roadmap and the architecture that underlies it all. While in London this past week, I had lunch with one of our customers, and they kicked off the lunch with a 10-item “wish list” of features/improvements they’d like to see in Alfresco. No big deal, right? Microsoft must get feature requests all the time.

The difference here was that they also came to the table with development ideas of how to tweak our code to get there, and an appetite for involvement in the changes. In fact, we’re now hooking them up with one of our other customers that had some overlapping requests so that they can collaborate on our code. Try that with BMC, Oracle, SAP, etc. It just won’t happen.

I honestly didn’t expect this. I thought we had killed the pursuit of “fancy” in software. I assumed it was just the facts now; just whatever the vendor saw fit to drop on its customers. But there is room for fancy in software, and open source enables it. If you’re an open source entrepreneur, your goal must be to find ways to unleash Fancy in your customers. Don’t impose Fact on them. It didn’t work for Mr. Gradgrind’s pupils or children. It will no longer work for your customers.

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.