SM: In your eyes what makes OpenSource work so well?
BB: That is a question I first started to answer almost ten years ago. Back in 1999 I brainstormed quite a bit with Tim O’Reilly about what really made OpenSource work. At the time there were obviously companies like Red Hat emerging as support organizations, but I wanted to do something at one-level meta. I wanted to address the question in a more abstract form. My goal was to distill it down to a science, make it repeatable, and take the answer to the rest of the software industry. After coming up with a couple of different OpenSource business models I realized it was about the tools developers were using to foster a collaborative development. These are tools that are designed for wide area networks and transparency in the development cycle. They are designed for software initiatives where a core team of developers are surrounded by concentric rings of people who are involved at different levels. There are the naïve users who have questions or want to suggest new feature all the way to people who submit patches. Ultimately it was that question that was the genesis for CollabNet. We got our funding from Benchmark Capital in July of 1999. I hired Bill Portelli, our CEO, in September gunned for this opportunity.
SM: Can you tell us more about CollabNet?
BB: Sure! We realized that what was needed were robust tools for collaborative development. We started with a baseline which consisted of a couple of different tools forming sort of an integration layer. I went out and signed up HP and Sun as our first two customers. That really set an interesting tone for us. In Sun’s case they were starting to launch new OpenSource communities. Initially it was NetBeans, then it was OpenOffice, then it was Java.net and all these others. We were an easy way for them to have access to these tools. We were running the infrastructure for them as a managed service.
SM: You were basically software as a service for an OpenSource community?
BB: Exactly. In HP’s case there was a different kind of use that I did not anticipate being as interesting as it has been, which is building OpenSource communities inside of the company and between the company and its business partners / developers. That model actually accounts of most of our business today.
I had never worked for a big company so I always assumed the software engineering management tools corporations buy had all of the development problems sorted out and it was just us cheapskates in the OpenSource world who were making due with simple tools. In reality corporations had no tools to enable engineering teams to work across geographical boundaries with insight into other teams efforts. We found a couple of people inside of HP who were very visionary and our initial work grew very quickly from a couple dozen users in their Printing and Imaging division into the standard tool for Printing and Imaging, their Enterprise group, and other groups as well.
Within the first couple of years they opened up to business partners. That drove as very interesting design criteria for us in terms of how to facilitate transparent tools built for the wide area networks which also have very sophisticated permission levels. When HP brought in developers from Microsoft, they knew that they would give them observation rights on some projects, co-developer rights on other projects, and that the Microsoft developers would never need to know about the rest of the software being built at HP. That flexibility was essential for building collaborative communities in a really complicated environment like an enterprise.