It’s been a lot of fun discussing the continuous support system with folks over the past few days, and with customers over the past year, as its technology SourceLabs has invested in heavily – and quietly – since the day we were founded. It’s always nice when a new innovation finally enters the public world. And it’s been hard to keep quiet for the the past two years while we developed and refined the system to meet the demands of our large enterprise customers.

The first time we really started talking about the system was before SourceLabs was founded. I drove down to South Seattle to meet Will Pugh, an extremely talented engineer who had recently left BEA Systems, where he had worked with me. I was excited about the opportunity for Will to join me in a venture I was summarizing at the time as “Dell for Software”. Will picked one of his favorite lunch spots in his neighborhood, and we met up, and I pitched him the idea for what I was then calling “Stratocaster” – a reference to the guitar I had recently learned to play, and the inspiration that Napster had given me for thinking about the open source community.

As Will and I began talking, he very quickly got the idea – and something else. I told him how nobody had really focused on being great at support and maintenance for enterprise server software, which is a bit odd since it’s a $10 Billion-plus market. I said that at the new company, the smart people would focus on doing a great job at support and maintenance, rather than building new features for software that was already commoditized. As Will listened, I could tell that the lights were going off in his head.

Will immediately began talking about ideas he had for what those “smart people” would work on building. Technology that would actually gather information about the operation and failures of open source software as it ran, so that support could be faster and more effective. I deferred completely to Will on this because it wasn’t an area of my expertise, and he had a lot of experience in building debuggers.

As we kept talking, it became clear that we’d be able to gather a lot of useful information. What could we do with this information? We started to brainstorm about developing a repository of all the information we had gathered, so that each time a customer encountered an issue, they could benefit from the experiences of the past customer, and as a result often find their problems more quickly resolved not just because we had the technology, but because had the information required to enable support engineers to do their jobs better.

Later I started chatting with Cornelius Willis, who had run developer marketing at BEA, and knew it would be great to have him on board to found the new company. We’d get together at a cafe near my house, Zoka, and chat about strategy. Cornelius was super skeptical at first for how SourceLabs could be different from pure “services” businesses, and how it could be competitive with some of the largest companies around. We started to brainstorm about what sort of technology we could build to accomplish that, and after more than a few coffees together Cornelius agreed to co-found the company with Will and I.

It seemed like we had come a long way, but the hard parts – actually designing and building the technology – were still ahead of us.

• What would be an efficient way to represent, search, and query the huge amounts of data we were generating?
• How could we design and implement probes that communicated securely with the outside world, and that had minimal impact on the production system being probed?
• What would be the “right” user interface for interacting with and subscribing to all this information?
• How would we handle the diverse formats of data throughout the Internet, and the fact that those formats change (and the data can become unavailable) unpredictably?
• How would we make sure that the probes enabled customers to protect the privacy of their information as much as they desire, without creating a huge amount of overhead work or diminishing the effectiveness of the probes?
• How could the probes be implemented so that they could be dynamically reconfigured “on the fly”?
• How could we make sure that our database and our daily notifications could scale properly to ensure the quality of service our customers expect?
• How could we make the notification services completely customizable as well as scalable?
• Etc.!

We’re proud of the work the SourceLabs engineering team has done, and are excited to now be talking about it publicly. A lot of the features we ended up implementing were not dreamt up over lunch or coffee but through hard work with customers and by our engineering team. And we’re constantly listening to additional feedback. We have a bunch of ideas for where to take the Continuous Support System, but we’d love to hear your feedback too.

Open source vendor SugarCRM partners with Microsoft, the latter a company not known for fondness of free software and with clearly stated intentions in the CRM space. Oracle, the world’s larget database vendor (by far) buys not one but two open source database companies. Jboss announces a partnership with Microsoft, probably the most unlikely pairing of all, given Microsoft’s double distaste for Java and open source. At the time of this writing Oracle’s acquisition of Jboss is imminent.

What gives?

Let me digress for 2 paragraphs. The last 5 years have been really really bad for 95% of all software vendors. Companies like BEA Systems, Siebel, and Borland (just to name three, but pick just about anyone) have struggled mightily. Notice I didn’t even mention Sun. The 5% who’ve done comparatively well? Oracle, IBM, Microsoft, and SAP. It’s been like a nightmarish realization of supply-side economics gone amok – the rich get richer, everyone else struggles. Why? Large companies haven’t been spending much money on software (they’ve been digesting a lot of shelfware they bought in the go-go days) and CIOs have become more and more risk adverse – a lot of money was ill-spent, and the economy as a whole hasn’t been great, so their budgets have been tight and they’ve focused on keeping costs down rather than starting new projects. (This seems to be starting to change a bit, but don’t hold your breath…) In an environment like the one we’ve had over the past few years, customers have run to safe harbors – the large software vendors and “solution providers” (a fancy term for custom software services and bundled offerings – what IBM and HP do essentially.)

This doesn’t mean, of course, that innovation and entrepreneurship have stopped. It’s been alive and well – primarily focused on “new business models,” namely software as a service and open source. Poster children: RedHat and Salesforce.com. From the ashes of any downturn new businesses are born. MySQL and JBoss are two smaller companies on similar tragectories. (There’s certainly been some excellent technical innovation as well – out of pure stubborn resistance to jump on any sort of Web 2.0 bandwagon, I’ll cite XenSource and Azul as examples.)

With this background, back to the subject at hand. If you’re a giant software or services vendor, in today’s market you know that you’re going to get a good chunk of a customer’s business, for the reasons stated above. Your goal becomes figuring out how to “grow the pie”, and how to compete with other large companies. How to go about doing that?

There are four easy rules for a huge software vendor these days:

• Make sure your software works easily with all the other software your customers are using. This increases the number of projects and customers you can work with.
• Co-opt innovation where you find it (by partnering, acquiring, or in the case of standards, simply promoting and adopting)
• Acquire small companies when they’ve established that they have something customers want, but customers clearly would prefer to buy from you. This is a super low-risk strategy that, I would argue, is behind the Oracle/Jboss combo.
• Don’t let smallish companies growing quickly get large enough to have their own momentum – beat them or buy them.

Most of the partnerships and acquisitions we’ve seen can easily be attributed to one or more of these four strategies. Moreover, most of the “low hanging fruit” – the medium sized companies like Peoplesoft, Siebel, Rational, etc. —have been gobbled up. The Larry Ellisons of the world have turned their sights on smaller fry. It’s an interesting environment where the companies that count are the largest and the smallest – and the “tweeners” get left behind.

So if these conditions stay true, what could be on the horizon? Clearly more partnerships between upstarts and large vendors. But what about our poster children? RedHat and Salesforce.com are certainly threats to the large incumbants if they continue their success. The Salesforce.com case is easy – I’d look for companies like SugarCRM to continue to land big-name partnerships until they are successful enough to be bought. RedHat is a more difficult case, but it’s certainly hard to imagine that there are calm waters ahead for the crew from North Carolina.