Asay the Alfrescan

Slashdot carried a story earlier today entitled “Why Is Commercial OSS So Expensive?” He was referring to embedded software, and his experience is 100% contrary to my own experience. (My background is in open source embedded software.) He says:

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.

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.

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

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

Here are a few sample projects I pulled:

• Mambo

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

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

Thanks for sharing, Leon!

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.

A new project - reasonably far along - just popped up on the SugarForge: Alfresco/SugarCRM integration. I’ve been looking forward to this for some time: the best of open source CRM combined with the best of open source ECM.

We have a few mutual partners working on the project now. I’d highly recommend you take a look, and hopefully get involved.

SearchOpenSource has a great interview with Kevin Cochrane, Alfresco’s VP of Engineering, WCM (and employee #4 at Interwoven and that company’s creator of TeamSite). Kevin is a great guy and a strong asset for Afresco.

Among the gems from the interview:

What challenges do you expect, or want to tackle in this space?

Cochrane: I don’t think there are so many challenges today as there are opportunities. Historically, what customers have seen from the commercial vendors are products that are very difficult to use, to install, and get up and running. With Alfresco, what we will attempt to accomplish with our platform is an extremely easy to install and run application.

We aim to make it the Web content management process as easy as saving a [Microsoft] Word document to a network drive. Our challenge is so to get up and running, but we have the opportunity to get Web content management to a place that is as easy as Alfresco has made content collaboration. As an example, when a user is done with a Word document and wants to save, they should be able to have right click and save, then have that document sent out to multiple Web properties.

And another:

Was Interwoven well-versed in open source technologies? How will working at Alfresco be a different experience in this respect?

Cochrane: In my opinion no commercial vendor is as well-versed in open source software as they should be. This is not unique to Interwoven, but to the entire space. Coming from Interwoven to the open source world, it was remarkable - the level of innovation and the degree of participation in the developer community….

At Interwoven I saw the need for a clean-slate approach to enterprise content management, for leveraging new standards and technologies to build a common platform to support such key business needs as collaboration, document management and Web content management. I believe Alfresco is an exact match for the needs I see in the marketplace. The large, established vendors are not meeting the demand for easy-to-use, easy-to-deploy applications that are accessible to the average developer, departmental business manager or SMB.

At commercial, proprietary platform firms there are also very lengthy development cycles, and you have to go through the sales reps and sales engineers to get engineers to communicate. There are all these filters to get the engineers to connect. At Alfresco the wonderful thing is the engineers are on the front line and are connected with those who deploy products. They are on the product roadmap together. There’s not some project manager in an ivory tower handing down commandments on what thou shall not release.

I’m in Caracas, Venezuela right now for customer visits and partner training. I’ve never been here before, and was super excited to have the chance to visit such a great city/country.

I was less excited, however, after an hour in the car from the airport, with another 1.5-2 hours to go. Normally, the trip from the Caracas airport is 30 minutes to downtown, but the “Viaduct” (bridge connecting the two) is down, requiring a HIGHLY circuitous, corkscrew route from the airport to downtown. It was hell. Pure hell. I actually only made it half-way before I revisited my Delta Airlines meal. Enough said.

Why is the bridge down? (And, more appropriately, why is there only one direct way to get to the airport?) Because the mountains between which it is suspended have been moving, causing the bridge to buckle. When it was built ~50 years ago, no one thought about complex foundations to flex and give. Who can blame them?

Today, however, the result of this architecture is clear: a broken bridge and my near insanity at being cooped up in a car for nearly three hours on super-windy mountain roads.

Much of today’s software world is made up of Caracas bridges. In my world (content management), there isn’t a major proprietary ECM product that was built in the last six years. Documentum is 15 years old. FileNet, Vignette (did a major redesign, much to its customers’ chagrin), Interwoven, etc. All are burdened by antiquated architectures. The same holds true of other product spaces (ERP, CRM, etc.).

Part of the value open source brings, then, is simply novel architecture. And because that code is open, the architecture tends to get vetted early and written “right” or the project dies. Open source, then, offers a way to build the “Viaduct” in a transparent manner, resolving architectural snafus early on.

So, if you’re an enterprise buyer, do you want to invest in a stodgy, decrepit, proprietary architecture? Sure, it probably has more features, but that’s a temporary advantage. Besides, why not invest in a modern, flexible architecture and build up the product through a system integrator, rather than trying to chisel down the calcified remains of an overwrought, overweight proprietary architecture? In my experience, the former road is cheaper and more likely to lead to IT happiness than the latter.