Archive for February, 2006

The rise of software libre (Mea culpa)

Thursday, February 23rd, 2006

So, it’s actually not uncommon for me to find out that I’m an ignorant Muppet. But it’s somewhat uncommon for me to admit it publicly. ;-)

I’m in Venezuela meeting with partners and customers, some of which are government agencies. In so doing, I’ve asked for further clarification on Venezuela’s legislation (Decreto No. 3.390 [PDF download]) mandating the use of open source software. I’ve criticized this (and other governments’ open source legislation) in the past, not because of a disregard for open source software (My entire career has been spent promoting open source), but rather because I dislike government edicts that require use of a particular kind of software.

As it turns out, the Venezuelan legislation preferences open source software, but does not mandate its use in areas where it might not be a good fit. So, for example, the government isn’t throwing out its SAP ERP software (yet!), but will shift to open source ECM, CRM, operating systems, office suites, etc. because those currently have strong open source alternatives.

This, I believe, is smart legislation. In talking with people here, it’s clear that money really isn’t driving these decisions. Freedom is. Freedom from lock-in to vendors whose interests are not always aligned with the government’s. Freedom to build up the local economy by keeping Bolivares here, rather than wiring it back to the US, Europe, or anywhere else.

Here’s a relevant part of the legislation (in Spanish):

Articulo 1. La Administracion Publica Nacional empleara prioritariamente Software Libre desarrollado con Estandares Abiertos, en sus sistemas, proyectos y servicios informaticos. A tales fines, todos los organos y entes de la Administracion Publica Nacional iniciaran los procesos de migracion gradual y progresiva de estos hacia el Software Libre desarrollado con Estandares Abiertos.

Chavez is on the march….

Open source and modern architecture

Thursday, February 23rd, 2006

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.

Choosing a systems integration partner

Thursday, February 23rd, 2006

Given the positive feedback I’ve had on the idea to bring an implementation/systems integrator focus to OSBC Boston 2006, I figured I could start the conversation here by discussing some of my findings about choosing a strong SI partner.

In my experience, different SIs bring different strengths, and it’s not clear that one is necessarily better than the other. Some of the different types I’ve worked with at Novell and Alfresco:

  1. Open Source Savvy. Systems integrators with a strong open source background can be a huge benefit in pitching reluctant customers. You don’t waste time trying to bring them up to speed on the “Why open source?” question, and they generally have solid customer references to help newbies “cross the chasm.” The downside to open source SIs is that they don’t always have good depth in a given market (CRM, ERP, ECM, etc.). Worse, because their backgrounds tend to be with “in the wild” open source projects, they sometimes have a hard time pitching commercial open source alternatives.

    It’s therefore imperative that you work out a clear sales strategy/competitive differentiation with your open source SIs. In Alfresco’s case, for example, one of our partners - Cignex - has traditionally been a Plone shop. They found that a number of customers wanted a Java-based ECM offering (Alfresco is J2EE-based), however, and have established clear guidelines for when they pitch Alfresco versus Plone, making us comfortable that they’re not undercutting us or underselling us.

  2. Proprietary Solution Savvy. These are SIs who have a long track record in implementing SAP, Documentum, Siebel CRM, etc. These partners are great because they tend to have excellent customer references and have felt their clients’ pain acutely, which usually stems from implementing overly expensive, inflexible, and featured products. They tend to see open source offerings as a low-cost alternative to their more costly, proprietary partner offerings.

    The downside with these partners is that they tend to lack a sophisticated understanding of open source and therefore don’t always pitch this value accurately or emphatically. You need to work with these partners to help them see open source as more about flexibility, choice, and innovation than it is about cost.

I haven’t found either type of SI partner to necessarily be generally better than the other. Each has its strengths and weaknesses and should be brought into deals accordingly. I have found, however, a few more things:

  1. Size doesn’t matter. Some of our best SI partners are 3-5-person shops. They are hungry to work with us and do exceptional work.

  2. They’re not in it for the license revenue. Because open source solutions tend to cost less, 10-50% in margin won’t mean as much as it will in a bloated, proprietary software deal. But the good news is that there is still plenty of money for them to make in implementation. Open source doesn’t obviate the need for customization to an organization’s business processes.
  3. SIs are absolutely critical to open source’s success. A successful open source business model is one that scales well beyond its own employees. SIs give an open source company leverage and range. Building a robust SI channel is therefore one of the most important things an open source startup can do (in addition to building out a strong inside sales team).
  4. To pay or not to pay? At Alfresco, without exception our best SIs are those that invest the most in Alfresco. They’re the proactive partners who get neck-deep in the code and end up understanding it as well as we do. Generally speaking, they’re also the ones who invest money upfront in our partner program. I’m not sure whether the commitment is a consequence of having invested actual dollars, or if it’s a trailing indicator, but the two invariably go together. Lesson? If someone isn’t willing to invest at least $2,000 in your company (in order to make a multiple of that on their first deal alone), are they really that committed to your product? Probably not.

I’d be grateful for any other insights people may have into this. Please share.