“Everyone does globally distributed development, these days!”

Jack Repenning about CollabNet's acquisition of the “SourceForge Enterprise Edition” business

Source: Translated from OBJEKTspektrum 04/2007 (July/August issue)

Jack Repenning
CTO

After the acquisition of the “SourceForge Enterprise Edition” software business by CollabNet we wanted to know about how the future product strategy looks like. What means the deal for customers, what changes do they have to face und what advantages might they be able to profit from? Here are Jack Repenning's replies from a Q&A session with OBJEKTspektrum.

Jack Repenning is Chief Technology Officer at CollabNet. Jack joined CollabNet in 2002; as chief product architect he was primarily responsible for building the product architecture that enabled CollabNet grow its current user base to well over one million users. Jack is also an early member of the wildly successful Subversion open source project, a version control system that is widely viewed as the de facto new industry standard.

1. The news regarding CollabNet's acquisition of Source Forge created a lot of attention. Can you describe the content and motivation of this agreement for our readers?
   
   The SourceForge Enterprise software business, product and team have been transferred from VA Software to CollabNet. This allows VA to concentrate on their core media businesses, the Slashdot ("/.") and SourceForge.Net and related web sites, while concentrating the best technology and people in the Enterprise and Managed Community web-hosted software collaboration business under the CollabNet roof.
   Note: On May 24, VA Software announced that it changed the name of the company from VA Software to SourceForge.
   
   
2. What exactly is meant by the statement in the press release "30 month media relationship for online advertising services", that SourceForge will make CollabNet known on their web pages?
   
   As part of the acquisition of the SourceForge Enterprise business, CollabNet will continue to advertise on SourceForge.net and related developer-focused web properties.
   
   
3. How is this related to CollabNet's joining OSA the Open Solutions Alliance; what is the motivation for that move?
   
   While there's no direct relationship between these two moves, both reflect CollabNet's commitment to providing the best value to our customers. OSA is forging consensus on standards for interconnecting the components of a web-centric site, and CollabNet's products need those standards in order to integrate with existing and new services within the customer and community environments.
   
   
4. What are the biggest challenges through the CollabNet/SourceForge cooperation?
   
   The biggest challenge will be providing a smooth progression of service for our customers while converging on a single platform with the best of both original products.
   
   
5. And the expected benefits?
   
   From the CollabNet side, we will bring reliable, low-cost hosting, rich security and access control, a high degree of configurability, scalability to the largest installations, and a constantly growing suite of core features. From the SourceForge Enterprise Edition side, we will bring rich extensibility; elegant, consistent interfaces; and easy on-site installation.
   
   
6. How will the end-user be affected by the change?
   
   Regardless of which product you've been using you'll be seeing new things from the other side. You'll be making some choices, whether to switch to a new tool or stay with the old one. In some cases, additional features will cross over from one side to the other. But you'll continue to use your current system as it evolves into the new, converged one.
   
   
7. What percentage of your users use CollabNet's tools to manage globally distributed development projects? Do you expect this to increase through the acquisition of SourceForge?
   
   Everyone does GDD, these days! Both CollabNet and SourceForge Enterprise Edition have been enabling that for years. I don't foresee much increase, because I think GDD has conquered the world already.
   
   
8. CollabNet is often viewed as offering tools and services that are applicable if you do open source development. However to my understanding open source is not a requirement for using CollabNet's tools, but that does not seem to be so broadly known?
   
   It's really quite the opposite: CollabNet was formed in order to bring the techniques and tools proven in the Open Source community to the enterprise. CollabNet's open-source roots go deep, but our product and mission is into the enterprise. The open source community has achieved some incredible things, in some cases things that the enterprise community hasn't managed. GDD is certainly one; everywhere you find enterprises non longer satisfied with a "throw it over the wall" model of out-sourcing, looking for ways to distribute the work more finely, collaborate more effectively, track more closely.
   
   But classic enterprise approaches can't cope with three inescapables of GDD: the speed of light, time zones, and turn-over. The time it takes a signal to travel half-way around the world is never going to get much smaller than it is today, and it's never going to equal what you get within a single city or building: the tools must be designed from the ground up to respect network costs. Just as intractably, the sun refuses to rise at the same time everywhere: your management style just can't depend heavily on everyone being alert at the same time. And on every front, we find people working for the company for shorter times, tasks being reassigned within the company more freely: an explosively growing need for constant training of "newbies" into "committers." The open source community found ways to succeed despite these obstacles, some rooted in tools, some in process, some in culture. CollabNet brings these to the enterprise.
   
   At the same time, some of the open source innovations just do not fit into the enterprise context. The most popular example is scheduling: the community has sometimes taken a casual attitude toward schedules and commitments that is completely unacceptable to an enterprise. There are other examples as well, including backwards compatibility, commitment management, and at times quality and stability. But these problems are not essential to the open source process, they are only side effects of the core dynamic of volunteerism. The enterprise process has long studied how to get the less sexy bits done well, and it's possible to blend enough accountability into the open source process to ensure these things.
   
   
9. Often you must provide potential users with an Return-on-Investment Calculation for moving to collaboration tools. But since many people-related topics are involved this is hard to measure. How do you go about trying to measure the relative costs of a single-site team, a multi-site team using CollabNet, and a multi-site team not using collaboration tools?
   
   There are simple calculations of "hard ROI," based on the cost of the tools, the hardware to run them, and the people to keep them running, and they tell a powerful story right there. But far more valuable is the savings in rework and underutilized talent. For the "hard ROI," there are many studies by analysts, practitioners, and vendors. For the rest, the best approach is an internal pilot, so people can see with their own eyes how it all works.
   
   
10. What do you view as the upcoming trends in the area of collaboration tools and services?
    
    Clearly, there's a proliferation of tools going on: wikis and blogs and feeds, tags and social networking. These tools overlap a bit, and are still seeking their niches, and of course their primary application at the moment is, in some case, not to development collaboration at all. But they represent a core need, presently inadequately met, and very promising for this space. The issue here is the "scalability of trust": when collaboration involves reusable components already in production, you need ways to judge whether some new discovery will live up to its hype. In a collaborative environment, the health of a component is nothing other than the health of its community: no product is ever done, perfect, easy to use, instantly installable. These social-networking tools provide ways to "audition" the community that surrounds the component, and that provides a crucial piece of the reusability puzzle. For this reason, I think we're going to see these tools move rapidly from useful things on the side, to core tools with demanding needs for integration into the existing suites. What that means, exactly, we'll all just have to wait and see. But I don't think we'll wait very long!