Asay the Alfrescan

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.

Peter Galli of eWeek has an interesting article entitled “Can Windows and Open Source Learn to Play Nice?”. It’s a decent attempt to bridge the (apparent) divide between Microsoft and the open source applications, and other software, that run on Windows.

“Open source is a way of building software and, in its most basic sense, there is nothing incompatible [between] the concept of open source and commercial software.

“But the GPL has an inherent incompatibility that is, to my knowledge, impossible to overcome,” Bob Muglia, the senior vice president of Microsoft’s server and tools business, told eWEEK in an interview here at Microsoft’s annual TechEd developer conference on June 12.

A commercial company has to build intellectual property, while the GPL, by its very nature, does not allow intellectual property to be built, making the two approaches fundamentally incompatible, Muglia said.

Licenses like the BSD (Berkeley Software Distribution) and commercial software, on the other hand, are quite compatible with one another, he observed.

“We are open to ways of working with the open-source community broadly, and even in the GPL space we are trying to find ways in which we can build bridges to GPL, but the bridge has to be carefully constructed,” Muglia said.

I think, first off, that Bob needs to drop “commercial” versus “open source.” I have to think that Red Hat considers itself very commercial. So, though the nomenclature might suit you, Bob, try using the more accurate term for Microsoft: closed. Proprietary. Whatever. I don’t think you view the word as

Secondly, the GPL flap strikes me as much about nothing (and I’ll resist making the joke that Microsoft worries GPL’d code might infect its own code with things like security, quality, stability, etc. . Over half the downloads of SugarCRM, JBoss, Alfresco, etc. are on Windows. Not Linux. Not Solaris. Windows. And everything is just fine. No, these are not GPL products - they’re MPL or LGPL. But a GPL application could run on Windows with nary a hint of trouble for Microsoft. This is old news. Apparently, Microsoft hasn’t been reading the news for the past, oh, six years?

Speaking of “better late than never,” it seems that part of this open source outreach has been spawned by a realization that not everyone cares to run on Windows:

The goal, from both sides, is to meet customer needs, he said, adding, “This is just the more mature view of the way the world is evolving, and we want to make sure that if customers are choosing Linux or other open-source-based products that we have ways of interoperating and working effectively with that.”

Can I just say, “About time!”? I’ve been advocating this move for over a year. It’s a clear, important strategic move. But it has apparently been lost in the glaciers of Redmond. I credit Bill Hilf (and Jason Matusow, before him) with getting this moving. The next step, of course, is to help open source projects/companies interoperate with Office, and not merely Windows/IIS/SQL Server. Anything can run on Windows - that’s easy, and only marginally interesting. For open source applications companies, integration with Microsoft applications is the higher value partnership.

I genuinely think Microsoft wants to cooperate with the open source world. Not because it is generous, but because it is in its shareholder interest to do so. This is the right motivation for any corporation. It still has a lot to learn but, then, so does the open source world.

One thing that I wish is that Microsoft would cast aside some of its cherished positioning. Some of it was noted above, but here’s a final one that drives me crazy:

…[I]ntegration is tough in a distributed environment, and architectural boundaries have to be set up between components, which is a good thing, he said. Now Microsoft plans to do as much of that as it can in the future.

Open source, on the other hand, historically has had a tough time building integrated solutions in that distributed fashion, Muglia said, and, “Our customers demand that from us. So there are certain things we have to do that are core to our development and our customers that we can’t learn from open source because they are not doing that.”

The (major) quibble I take with Bob’s statement is that the kind of integration he’s talking about only works between Microsoft products (and even then not very well much of the time) - the rest of the world has understood “distributed integration” for some time, because we live in a heterogenous world. Welcome to it, Microsoft: glad to see you may have to play by the rules the rest of us live by, now that you’re winning a lot less often than before.

Come on in. The water is fine. Just don’t mind the sharks.

Well, actually, 100% of the world will wait on Vista, because it’s always on the horizon…never quite getting here.

According to an article in SearchSecurity.com, there are a myriad of reasons for this. Most interestingly to me, though, is that many of these same IT professions surveyed seem to have no hard-and-fast aversion to Microsoft products at all. The delay in their adoption seems to be similar to their past delays in adopting Microsoft (and any other new) products:

When Windows XP Service Pack 2 (SP2) was released nearly two years ago, most IT professionals said they were worried about compatibility problems and that they’d wait a while before deploying it in their enterprise.

The full release of Vista, the next big upgrade for Microsoft’s operating system, isn’t due out until early next year. A new survey though suggests Vista is already being viewed with skepticism similar to what was directed at SP2 in 2004.

According to a survey by Boca Raton, Fla.-based Amplitude Research conducted on behalf of Albuquerque, N.M.-based security firm VanDyke Software, more than half of respondents said they have no plans to deploy Vista when it comes out, despite all of the security improvements that Microsoft says will be baked into the operating system.

Amplitude culled the information after surveying 255 network and system administrators last month from a variety of industries. The enterprises also varied in size. Of those polled:

• 10.98% are testing the limited beta version of Vista.

• 19.21% are waiting until the public beta release to begin testing.
• 25.49% are waiting until the official release to begin testing.
• 5.09% have plans to deploy after successful completion of beta testing.
• 20% will deploy after successful completion of testing of the official release.
• 11.37% will deploy after Service Pack 1 for Vista is released.
• 11.37% will deploy only on new PCs with Vista pre-installed.
• 52.15% said they have no current plans to deploy Vista.

Of those who do plan to test or deploy it, 58.33% said their primary interest in Vista is its “enhancements,” while 30.12% cited “improved usability.”

To those of you interested in Vista’s “enhancements,” I’d recommend you get Macs. You’ll get double the improvements in stability, ease of use, etc., and infinitely more security.

To Microsoft, I’d heartily recommend you do with your product what (increasingly) everyone else does when they want to make it secure: open source it. Sure, this is a naive statement for a company that has been the poster child of Proprietary, but you would boost trust, arguably find a wider, deeper array of bugs before (and after) general release, and a more efficient distribution mechanism.

Try it. You’ll like it. Even Mikey likes it.

I’m reading through an excellent JMP Securities research note called “Turning the Software Model Upside Down: The Proliferation of Open Source.” [Subscription required.] It’s a good overview of the open source business phenomenon - the how’s and why’s open source is increasingly dominating software - but I particularly like its analysis of proprietary vendor’s likely responses to open source:

• Proliferation of enterprise license agreements (”ELAs”?). Large enterprise software vendors such as Oracle Corporation, Microsoft and IBM may aggressively pursue ELAs with customers. Our due diligence suggests Oracle has employed this practice over the past few years. ELAs reduce the cost advantages of open source software since they are often structured as “?all you can eat” type of deal. Effectively the marginal cost of deploying proprietary software goes to zero in some cases, reducing the cost advantages of open source software.

• Free software offerings from enterprise software vendors may crimp the low-end. Free versions of proprietary software products could slow adoption of open source software at the low end of the market. IBM, Microsoft and Oracle, for example, have all released free versions of their database products. As mentioned previously, Sun has gone a step further and open sourced a significant portion of its product line.
• Savvy strategic moves. Oracle’s recent purchase of InnoDB and Sleepycat illustrates the potential for proprietary vendors to slow the progress of open source software products through savvy strategic moves. With these purchases, Oracle now owns two of the most popular transactions engines that plug into MySQL database, not a trivial matter.

For the record, there have been very few “savvy strategic moves” by the big proprietary vendors. Generally, their response has been “Huh?” In CRM, ECM, ERP, and various application markets, the big vendors have reacted to open source with indifference or scorn, just as the operating system, database, application server, and web server vendors did before them. This is one reason it’s so much fun to compete against the FileNets and Documentums and SAPs of the world - they have no idea how much they’re being hurt, and won’t until it’s too late to stop the rising tsunami. I’m reminded of a great new Morrissey song:

You have killed me, you have killed me.
Yes I walk around somehow,
But you have killed me, you have killed me.

It will take a long, long time for these companies to dwindle, but they will. Maintenance contracts will slowly peter out over 5-10 years; customers will hang on as long as they possibly can. And then the vendor will capitulate to open source - far too late - or die fighting it.

Capitulation, incidentally, is not easy. JMP has a great chart (below) showing just how hard it is to make the transition to open source.

Basically, the only vendor that looks good on the comparison of company valuation to percentage of revenues derived from open source is the one company with a pure-play open source strategy: Red Hat. I think there’s a potent lesson in this.

Keep in mind that there’s a LOT of money in open source going forward. So you don’t want to fetter your ability to share in it. Here’s the total market:

And here’s where those dollars are going:

“Other” includes applications, among other things. It’s a great time to be in open source.

Don’t go half-way on open source. This will be the natural tendency of big, proprietary vendors. Your best first bet is the ELA strategy noted above. It’s a great way to lock-in your customers - not great for them, of course, but since when have proprietary companies cared about that? In my world, they’re using proprietary ECM repositories to lock in content/data and, hence, the customer. It’s a good tactic, though it’s only a temporary stopgap.

Eventually, unless you go open, you’ll go under. Sorry about that. It’s one of those harsh realities.

Enterprise software pricing is one of open source’s biggest opportunities…and biggest headaches. On the opportunity side, it’s a huge amount of fun to compete against the bloated, unconscionable prices of my proprietary competitors. There simply is no reason for an enterprise IT buyer to pay so much for so little.

On the “headache” side, enterprise buyers (not being foolish folks) recognized the disparity between cost and value some time ago, and have been demanding hefty discounts. (Because license fees are just Monopoly money anyway, enterprise software companies have heavily discounted them as much as 80%, anyway, to win deals and gain market share, as PeopleSoft did when competing with Oracle, as just one example.) The bad news for open source companies is that IT buyers don’t generally immediately recognize the difference between proprietary vendors’ funny money and the lower-margin, higher-value support and service-based prices open source companies offer.

Hence, open source vendors should go into a deal with a firm grasp on what their proprietary competition will likely offer. The best place I’ve found to gather pricing information is GSA Advantage. It has discounted (typically, ~10%) pricing that vendors use to sell to the US federal government. True, it won’t show you the actual deal a proprietary vendor is quoting a prospect, but you can generally assume the proprietary vendor won’t cut its prices (much) more than 50% on any given deal, especially with the consolidation in the market (as this article notes).

Once you have your competition’s prices in hand, you need to help customers recognize the different pricing models. Their upfront license fee? $500K (or whatever). Yours? $0. Their ongoing support/maintenance fees? Typically 18-20% of the upfront license fees. (SAP is currently experimenting with different tierings of support at different rates. Looks interesting.) Most open source pricing tends to be cheaper than even the support/maintenance charges from proprietary vendors. Call it out. IT buyers need to see that there really is no meaningful price comparison between most open source products and proprietary products: open source from established vendors is simply better software at an almost criminally low price.

With this established, there needn’t be much haggling over price. Unfortunately, on your bigger deals, there will be, because enterprise salespeople have taught enterprise buyers to distrust vendors and expect a high initial quotation to be dickered down. It will take 1-3 more years for buyers to recognize the value they’re getting at the outset with an open source vendor, but it will come. In the meantime, expect negotiations.

Just don’t discount your support/maintenance fees too low - after all, unlike in a proprietary deal where discounting means cutting a bloated 85-90% margin on a product (and maybe some sales commissions), discounting in the open source world quickly cuts into the support/engineering resources necessary to service the customer.

Your primary value isn’t your price, anyway: it’s in better software. Hold to that. IT buyers are smart. They’ll see this. They just need time to forget the abuse they’ve had from proprietary vendors.

Back in my international relations days, reading Foreign Policy and Foreign Affairs was an imperative. And yet I never found Foreign Policy to be nearly as informative as Foreign Affairs.

Unfortunately, I must report that FP’s coverage of software is even worse than that of international relations, if this piece by Caroline Benner of the University of Washington is any indication. Benner rightly points out that governments moving to open source should be thoughtful, not knee-jerk, in so doing. But that’s about all she manages to say, and not as well as others before her.

Here’s the best section from the piece:

…[G]overnments tend not to like software they can’t audit for trapdoors that would allow an outsider access. Many countries also argue that open source is better than proprietary software at adapting to local needs, because you can change the behavior of the program by changing its code. With tiny budgets to spend on foreign-produced information technology and little infrastructure to create their own, open source looks like an attractive way for poor nations to gain access to the information age.

Trouble is, the benefits of open source are not always so clear-cut. Software is too complicated a creation to be captured in rhetoric, and assertions about some of the technical benefits of open source fail to tell the whole story.

Consider the issue of security. In a 2002 letter to Microsoft, Peruvian Congressman Edgar David Villanueva Núñez noted that, “Relative to the security of the software itself, it is well known that all software (whether proprietary or free) contains ‘errors’ or ‘bugs’ (in programmers’ slang). But it is also well-known that the bugs in free software are fewer.” Yet, ask computer security experts and they’ll tell you that’s not necessarily true. Software, with its millions of lines of code, is so complicated that experts don’t know for sure that open source has fewer bugs, nor can they say with certainty that having fewer bugs makes open source more secure. “There are really two reasons that it is very difficult to know whether software is secure,” says Stanford University computer scientist Alex Aiken. “The first reason is that even the simplest software program consists of hundreds of thousands to millions of parts, and potentially all of these have to be correct, or the system may have security vulnerabilities. The second reason is that we have no technology for systematically checking that the parts are correct and fit together in a way that ensures security.”

In this section and throughout the short article, however, Benner misunderstands the security benefits open source offers. It’s not that open source is inherently more secure - it is, after all, just software that someone has written, just as proprietary software is.

The real difference is in the visibility both “good guy” developers and hackers have into the source code. If someone cracks a security flaw in Linux, for example, I don’t need to wring my hands and wait for Microsoft to fix it (at their leisure, and when it’s good for their quarter). Instead, any active Linux user with competency can report and/or fix the problem. It is the breadth of the developer population available to fix a problem - 24 hours/day, 365 days/year - that is arguably open source’s great security asset.

Sure, you might counter, this is true of the “big projects” like Linux and Apache. What about the others? Well, for these others, they don’t face the same malevolent hacker threat, in the first place. In the second place, even with 200,000 downloads, as an example, my own company gets plenty of outside feedback (from customers, prospects, and partners) on our code. It’s enough for our needs. In short, the security community scales with the security threats in open source.

Benner questions other open source benefits - like the flexibility to tailor software to local requirements - but while her caution is welcome, it’s not particularly interesting. Of course, no one should blindly adopt open source. By the same token, no one should blindly stay with proprietary software. Both have their strengths and weaknesses. I’d prefer to deal with the weaknesses of open source, rather than those of proprietary source. It appears I’m not alone.

I just finished Charlotte Bronte’s Jane Eyre, and have been reflecting on one of the closing dialogues between the protagonist, Jane Eyre, and her unlikely anti-hero, Mr. Rochester. (For those inclined to read the book - and you should (though you can largely skip 50% of the verbiage in the book - Bronte goes on and on and on with 2000-3000 words when 20-30 would do…a bit like me, I suppose - you should skip this next section, as it gives everything away.

Jane Eyre, previously engaged to marry Rochester, had left him when she found out he was already married (to a lunatic wife that lived in his attic and occasionally set fire to people or stabbed them - Bronte obviously had an active imagination). After nearly a year’s absence, she returns, only to find him blind (having lost his eyesight in a fire that his lunatic wife had started) and crippled. After some discussion, he asks her:

“…Jane, will you marry me?”

“Yes, sir.”

“A poor blind man, whom you will have to lead about by the hand?”

“Yes, sir.”

“A crippled man, twenty years older than you, whom you will have to wait on?”

“Yes, sir.”

“Truly, Jane?”

“Most truly, sir.” [At this point, Matt is blubbering in his airplane seat - I’m such a softie.]

“Oh! my darling! God bless you and reward you!”

“Mr. Rochester, if ever i did a good deed in my life - if ever I thought a good thought - if ever I prayed a sincere and blameless prayer - if ever I wished a righteous wish - I am rewarded now. To be your wife is, for me, to be as happy as I can be on earth.”

“Because you delight in sacrifice.”

“Sacrifice! What do I sacrifice? Famine for food, expectation for content. To be privileged to put my arms around what I value - to press my lips to what I love - to repose on what I trust: is that to make a sacrifice? If so, then certainly I delight in sacrifice.”

“And to bear with my infirmities, Jane: to overlook my deficiencies.”

“Which are none, sir, to me. I love you better now, when I can really be useful to you, than I did in your state of proud independence, when you disdained every part but that of the giver and protector.” [My fellow Delta passengers are eyeing me suspiciously, wondering why a) a seemingly male personage is reading Jane Eyre and b) he is sniffling as he does so.]

“Hitherto I have hated to be helped - to be led: henceforth, I feel, I shall hate it no more. I did not like to put my hand into a hireling’s, but it is pleasant to feel it circled by Jane’s little fingers. I preferred utter loneliness to the constant attendance of servants; but Jane’s soft ministry will be a perpetual joy. Jane suits me: do I suit her?”

“To the finest fibre of my nature, sir.”

“The case being so, we have nothing in the world to wait for: we must be married instantly.”

And so (nearly) concludes an excellent novel. And so, in turn, the novel reflects a great truth about people, generally, and open source software, specifically.

The best open source projects are those that invite and facilitate community. I’ve talked before about the right mechanics for facilitating communities, but one of the key ingredients - perhaps the key ingredient, is a sense of community within a project. People must feel that they belong. As with the TV show Cheers, “You want to be where everybody knows your name.”

Lest this be passed off as a trite or easy-to-accomplish task, let me give some examples of how open source companies (including mine) routinely get this wrong.

1. Coding in private. It is a natural human tendency to want to keep our work private until we feel it suitably presentable to share. At Alfresco, we’ve fallen into this error several times. In one case, we were working on an integration with SugarCRM. Customers and partners kept asking for integration between the two, and we kept promising “We’re working on it, and will be releasing it soon.” But what they really wanted was both visibility into the project - they wanted to be able to go to our forge, or Sugar’s, and see the work in progress - as well as the ability to participate in the project. We ultimately rectified this and posted the ongoing work, but we should have opened it up from the start. Perhaps, had we done so even before we started coding, a partner or customer would have taken up the project on their own, allowing us to spend our development resources elsewhere.

   Open source companies shouldn’t behave like this. Our strength is in permeability. Roadmaps, pricing, code, etc. should be open, so that they can be forked or augmented in the best directions. Yes, there will undoubtedly be times when we develop initial betas of features/technology/products outside the public eye for competitive reasons, but generally, the inclination should be toward openness.

2. Investment in a community engenders devotion to that community. This seems intuitively wrong. One would think that those organizations which require least of us are those we’ll prize most, but the inverse is actually true. Not to wax religious, but if you look at the fastest growing religions in the world, they’re generally those that demand the most time, resources, etc. of their members. John F. Kennedy is famous for telling the American people not to ask what the country can do for them, but what they can do for the country. Parenthood is the same: it’s absolutely insane that I have four children, since I’m one of the most selfish people on the planet when it comes to my time. The more they demand of me, however, the more I appreciate them. The principle seems clear: we want to give to those things that need us (or that we believe need us - my daughter, Greta, seems to do just fine without me .

   Now, in software, I’m not suggesting that CIOs will drop boatloads of cash on projects that are “needy.” Not at all. Rather, I’m saying that there will be more psychological connection to software that allows us, even encourages us, to give to it. I can much more easily walk away from a failed financial investment than I can an investment of my time, reputation, and interest. Norm was never going to go to a different bar, not with how much Sam, Woody, Cliff, and the rest needed him.

3. Open source communities, then, will be strongest when they actively court new entrants. Related to #1 above, it’s easy to structure a “community” as a gated community that allows only the privileged few (usually a company’s employees and partners). This is no community at all.

   To encourage community, code needs to be modular (to make it easier to contribute in small doses - most third-party open source development is what I call “drive-by development”), forums need to be open and well-maintained (SugarCRM, which does commercial community better than anyone else I’ve seen, made its best investment in Clint, one of its founders, who actively works with its community to make it a welcoming place, and to ensure questions are answered), documentation needs to be solid (to make it easier to grok the code and get started), and it must quickly become community-maintained, if company-led (If the vast majority of the most active members remain the company’s development team after the first 6-12 months, you’re doing something wrong).

4. The company must be willing to relinquish (some) control. Related to the above, at some point the company must be willing to be forked. On its own forums. Otherwise, it doesn’t feel like a community of equals, and no one likes to be subservient. I’m not arguing that a company should invite forking of its code, but rather that without a willingness to see this happen, it likely holds too strong a grip on its community, which will stifle interest in the community. Jane says it well when she alludes to her preference to be a full partner in the marriage (now that she’s needed), rather than a doted on, half-servant to her husband. Strong communities take the risk of being forked (as Mambo/Joomla was in my ECM world). This is a good thing. Painful. But good.

Reading back on this, I may have taken Jane Eyre too far, but the core principle is true: one of the greatest “lock-ins” an open source company can hope to achieve is the emotional satisfaction a customer or partner has when it becomes a valued member of that project’s community. Investing in the code one licenses makes for committed, happy customers. Community matters.