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.