Once More unto the Breach

Conversion Rates (Again), Open Source Business Execution, and JBoss

Readers know I disagree with the facile answer that businesses that use open source software need to "convert" their user community into customers. I've laid out my concerns in two blog posts over the past couple of years (here and here). Today, reading Matt Aslett's (always useful) 451 CAOS Links I came across this gem from David Skok on developing the JBoss business pipeline.

If I had to summarize my overarching concern with conversion discussions (and wearing my customer hat), it's that sales and marketing types confuse conversion with selection. They're trying to jump start leads by applying historical pre-web lead qualification thinking in a world where the web allows potential customers to self-educate and then self-select. The process and thinking that goes into this JBoss case study isn't simply good for open source related business strategy. (I really wish we'd had this level of process and the tools to support it 15 years ago when we started Softway Systems.) Quotes that stood out for me:

The first question we looked at was: Did they know the names of the people that had downloaded their software 5 million times? The sad answer was no. Not only did SourceForge not allow them to collect names, but even if they did allow it, there was clear evidence that developers would simply not go through with the download if they were asked to provide their name.

Following one of the key principles of this methodology, we immediately realized that they needed to find a motivation to get the customers to provide the company with their contact information. The best motivation appeared to be the documentation, that they were currently selling. There was one big problem: selling the documentation was resulting in $27,000 per month in revenue, which was paying the rent and several peoples’ salaries. To me it was obvious that this was a small price to pay to get the names, but to the JBoss team, who had battled their way to get every dollar of revenue, that was less obvious. We debated this issue over the next three months, but finally they gave in and switched on the offer. It turned out to be a huge success: over 10,000 leads started pouring in every month. Over time this grew to 16,000 leads per month.

And ...

Later on the process, JBoss was able to look back at the customers who had actually bought the product and close the loop, by testing whether they had predicted the right events as qualification events. They did a lot of analysis to refine the events based on this information. Several of the original assumptions, based on common sense, turned out not to be true. For example, the amount of time that a lead spent on the website had little impact on their likelihood of becoming an opportunity or a closed deal. The same was true for time spent using the Wiki or the Forums.

Here was a process used specifically to "weed out" (qualify) customers from the noise of lead potentials in user and developer communities using the web site. The entire article is worth reading and careful consideration within your business. This is how JBoss "went on to reach an annualized bookings run rate of about $65 million a year within two and a half years after starting the process." Execution requires the right team, but it also requires the right process.

The CodePlex Foundation and the Free Software Foundation

The Free Software Foundation commented on the CodePlex Foundation existence on Monday. Presumably it was a slow news day at the FSF. Richard well describes his concerns and brings it all down to the standard list of concerns on software freedom, gently extending it out to all the additional freedoms that must be in place to say you truly completely support free software. He makes some conjectures based on his concerns and definitions, and finishes by rolling it back to warn people to stay focused on the FSF mandate on software freedom and avoiding Microsoft traps.

Sam Ramji (acting president of the CodePlex Foundation) posted commentary on Tuesday to correct a couple of FSF opinions, demonstrating he does understand that commercial software companies can thrive on free software and that the while some members of the board of directors and board of advisors may be Microsoft employees or ex-Microsoft (me), there remains breadth and depth in the bench of people participating initially that have real experience in the commercial free software world.

Once again we're having the Democracy versus Capitalism debate. Really, we need to move on. This is not a helpful debate. It started in the mid-1990s in the broader FOSS community itself. It unfortunately informed and fuelled Microsoft's messaging around Shared Source through the early part of this decade as they tried positioning everything on a linear spectrum with words like "free", "open", "commercial", and "proprietary". It doesn't work that way. It's the precursor to the Free and Open Source Software Business Model debate. It's about as useful.

The one nit I would pick with the FSF debate with respect to the CodePlex Foundation is when it opines about their definition of "proprietary software". The OED gives us a slightly better definition. Proprietary as an adjective means:

b. Of a product, esp. a drug or medicine: of which the manufacture or sale is restricted to a particular person or persons; (in later use) spec. marketed under and protected by patent or registered trade name.

It's about property. All our free and open source software licensing works because the software is someone's property covered by copyright. Proprietary software, however, actually would mean protected by patents and trademarks. So, Fedora, Linux, MySQL, Apache, and so too I believe "GNU Emacs". We need to get beyond the debate.

Stallman does say:

Someday we will be able to judge the organization by its actions (including its public relations).

I'm fairly sure the CodePlex Foundation will never live up to the FSF definition of software freedom purity, but I am looking forward to getting more organizations to contribute software and collaborate on development using free and open source licenses. And that's a pretty good thing.

Making Money from Open Source and the Business Model Debate

Matt Aslett makes great observations about open source business models in a recent blog follow-up discussion:

I am very glad that they took that decision, because in hindsight the statement “there is no open source business model” would have been inaccurate in the context of our report. We identified that there are multiple models used to build a business around open source: theoretically hundreds.

The 451 Group did a lot of research as they developed their model of discussion, and their definitions around development model, license choice, and revenue trigger are great. But it still feels like they start falling victim to the shades of grey slicing problem.

I'm still more of a fan of the tool analogy. As a company, you have a certain budget to spend developing the product, it's marketing, sales and distribution. Imagine a proper old hardware shop where you have a certain budget and need to figure out how you're going to spend to buy what tools from which aisles (development, marketing, sales, legal) to launch and build (and maintain) your product. "Open source licensing" is a set of new tools in the legal aisle and "collaborative community development" is a new aisle. It's not that there are hundreds of business models, but rather one can combine the tools in hundreds of ways. (Some ways are more proved than others depending upon the business.)

Indeed, "dual licensing" doesn't even belong in the open source licensing tools. It's an attribute of copyright law. I can license my intellectual asset to as many people as I want in as many ways as I choose. The Microsoft EULA attached to software at the local office supply store is different to the Enterprise Agreement signed when a corporation purchases based on a bundle of units and services is different again from a volume license to a smaller organization. No one accuses Microsoft of "dual" or "multi-licensing" their software. The fact that MySQL began closed licensing royalties as well as selling service agreements subscriptions (i.e. product) of their GPL distributed software does not mean that they invented "dual licensing".

The fundamental question around which this all revolves is the confusion embodied when one asks, "How can you make money when you give the software away for free?" Large "software" companies (Microsoft, SAP, Oracle, Adobe, etc.) have spent a lot of time questioning the scale of "the business model(s)" rather than looking at the opportunities the tools provide. In the end, they need to understand that it's not the "software" that a customer is buying but the solution and the support and maintenance and certified tested warranted removal of risk embodied in their product packaging and testing capabilities. (This is a core competency Microsoft has over most "software" companies when you consider the size of the test matrix defined by OEMs, ISVs, and device manufacturers that needs to be exercised between code complete and release-to-manufacturing.) Whether you call it a "license" fee and then charge 20% of the license fee per year for maintenance, or distribute the "license" fee into the maintenance "subscription" over time isn't a discussion about open source. It's just business.

Open Source Software and Product Management Tools

Matt Asay has a great blog post today on what Alfresco has learned with regards to their use of open source and product management, from both the perspective of their own product development feedback, as well as the strength of reuse by their customer base.

For years, our marketing has targeted buyers in these markets, pitching a low-cost, high-value alternative to proprietary ECM/WCM/RM.

Our customers didn't get the memo. While we were talking about ECM, many of the roughly 30,000 people downloading the product every month were using it as a foundation upon which to build their own applications, most of which would never be classified as ECM. They were creating their own category of infrastructure/middleware, using our technology.

The content application server was born, and we almost missed it, despite the fact that it was happening with our code. We were so busy marketing our vision that we almost missed listening to our users' vision(s). This new vision on an old way of using our product will significantly impact everything we do for years to come.

This is the sort of strategic edge I meant yesterday when discussing the extra tools a product manager has when open source software is added to the mix. Matt also points off to Vinnie Mirchandani's posted observations on how mainstream IT is rediscovering custom-built applications again. (Indeed it was exactly this sort of rationale coupled with open source software that was the impetus for the creation of Optaros in 2004 and why I went to work there.)

It really is about the engineering economic imperative of collaborative community development coupled with free and open source software licensing and enabled by the web and its ability to remove friction from the process. Developing good software is hard work, and we have shared software literally since we've been writing it. Brian Behlendorf gave a great talk around the time I began this blog where he made a number of key observations about open source repositories based on his experience. Open source projects don't "end" the way traditional development of IT applications end (sliding into withering maintenance) or vendor-led software products (being replaced by forced upgrades). Well run open source projects are much more organic. The software evolves and adapts. The building blocks are continually improving and very complex and powerful platforms can be constructed.

Carlo Daffura responded to yesterday's post with pointers to two posts supporting the idea of the economic value of open source software in product development. This certainly bears out our experience from 1995-1999 developing Interix (now Services for UNIX at Microsoft). Following one of Carlo's examples, Ari Jaaksi's paper is a fantastic overview of Nokia's experience launching the N770 and the cost savings to be had.

I essentially said yesterday that it's all just software business, that there is no "open source business model". Please don't misunderstand me. Open source licensed repositories and collaborative community development on the web substantially add to the tool set of product management on both the marketing and engineering sides of the house.

Open Source Business Models Redux

I debated again yesterday with a colleague on open source business models. I don't believe there is such a thing. Several well documented models have been articulated and debated (see Matt Aslett, Roberto Galoppini, Carlo Dafarra for excellent cogent examples) but when you get into the discussion it immediately degenerates when you try to assign certain companies to certain models. It degenerates further when you try to invert the discussion to argue that these stylized business models share attributes or can be applied together when discussing example companies. To me it's a useless rat-hole of a discussion.

It confuses audiences into thinking "open source" (or "free software") is different in a business context. Such confusion:

• Slows adoption by customers.
• Causes investors to hesitate.
• Can lead inexperienced start-up executive teams to chase ghosts instead of focusing on the business at hand.

Here's how I tried to articulate the counter-debate yesterday:

1. Customers buy solutions. In the immortal words of Theodore Levitt (Harvard Business School), “People don't want to buy a quarter-inch drill. They want a quarter-inch hole!”
2. Geoffrey Moore wrote "Crossing the Chasm" in 1991. As well as clearly articulating the Technology Adoption Life-Cycle (that he has evolved over the ensuing ~20 years), it helps people understand that developing a "whole product" offering (the core product and its complements) provides a better solution to customer needs and companies in a market that provide the best whole solution succeed better than their competitors and peers.
3. For technology solutions companies, there are a well understood collection of tools that product development management uses to deliver solutions.
• Buy or build complements and include them in the base product.
• Publish interfaces to encourage complement value add in an ecosystem of partners.
• Provide tools and frameworks to ensure partners can easily build complementary products in the ecosystem, providing an even bigger "whole solution" or enabling it to be re-positioned into new markets (i.e. onto new problems).
• Publish tutorials, how-tos, books, etc. to ensure people understand the product solution and can provide complement value add in the ecosystem. And publish here is a very loose word. Consider magazines and conferences and user groups here as well, and how the web helps or supplants each. The web removed enormous friction from this collection of related tools.
• Develop training programs to ensure people understand the product solution.
• Develop certification programs to ensure a good supply of knowledgeable people on the solution.
• Provide consulting services to ensure an immediate supply of knowledgeable people on the solution. Really though it could be other services as well (maintenance, repair, operational, etc.)
4. Companies can choose to sell (or license) the complement or give it away. In each case there's an opportunity for direct or indirect revenue. As long as the sum of the revenues is greater than the sum of costs of providing the whole solution (and operational margins are within tolerances specific to the "tool" or tactic or mix in the portfolio) the company is profitable and thrives. [Indeed, over time as value moves around the solution network — and it's a network not a stack — companies have a better chance of survival if they control more of the higher margin pieces of the network that is their whole solution or ecosystem. Think IBM with the breadth of whole solution they can deliver posting better than expected results September 2008 as the rest of the economy tanked.]
5. The larger the company, the more tools it likely uses in providing a whole solution. Maybe this is the corollary to the above statement. It certainly explains why we all rat-hole when trying to fit large complex companies into the stylized business models.
6. Adding open source licensed software repositories on the web and collaborative community development into the mix adds new tools, and evolves old tools:
• To "buy" vs "build" for complement value add, you can add "borrow" (IBM Websphere and Apache, and Red Hat and RHAS) and "share" (IBM and the original Eclipse project, and Intel and moblin).
• New companies (Red Hat) with lower margin business models (compared to the incumbent) can use F/OSS components to rapidly develop products that either serve new markets or serve the bottom end of an over-served market and then evolve over to or up into an incumbent’s market space. [Classic Christensen economics here.]
• It broadens the base of "users" which opens future customer opportunities and locks out competitors. (JBoss and MySQL used this tool.)
• Companies that participate in communities:
• Can rapidly develop complements to core offerings in their solution network (without necessarily building complete products), e.g. SAP and MaxDB and MySQL
• Can amortize dev/support/maint costs of software components across customers/partners/competitors (e.g. the vendors in the Linux Foundation today are no different than the vendors in the OSF 20 years ago sharing the development costs of OSF/Motif and OSF/1 as royalty free base technology).
• Get to interact directly with like-minded customer prospects in community, influencing customer/partner developers.
• Build brand awareness and trust through transparency of actions.
• Companies that participate deeply in communities better influence those communities (e.g. participate, hire, or acquire).
• Companies developing their own communities increase the opportunity for partners to provide complement value add as well as encourages engagement and commitment through participation and contribution.
• Companies can use F/OSS projects to reduce the cost of sales by allowing users to try and pre-qualify themselves as customers.
• F/OSS projects are an interesting publication strategy against competitors from an IP strategy perspective.

What all of this means is that the ideas need to be turned around. Technology businesses and technology adoption is well understood. We know how to measure successful companies and compare them. We understand the tools those businesses use to engage customers and solve problems. Open source software is a key economic driver from an engineering efficiency and software reuse perspective, but it also opens new opportunities and additional tools for product management to engage better with customers and improve both the top line and the bottom line.

But there is no open source business model.

Open Source Business Tactics in One Slide

I recently found a slide I used six years ago to explain open source software in a business context to Jim Allchin back when I worked for Microsoft and Jim was executive VP of all Windows. My job was to develop an open source engagement model, working in a team called Platform Business Management, which reported directly to Jim. Jason Matusow was responsible for driving the Shared Source agenda, initially working in the Windows marketing team and later as an immediate peer in PBM. The meeting itself would have been sometime in June 2003 (so shortly after Sun's threatened injunction against Windows). I tried to ground the tactics in product practices Microsoft already well understood and with company examples pulled from other large multi-billion dollar corporations, i.e. while our shining open source company examples might have been Red Hat, MySQL, and JBoss, they were meaningless examples to Microsoft based on revenue size. The slide worked. Jim understood why Microsoft needed to adopt its own open source practices, and how we might start. [There were other slides in the presentation discussing options for engagement and contribution that are confidential.] The execution was another matter entirely within the software product executive culture of the company, and isn't relevant here.

There are a few things to consider as you read the slide and the notes I used to present additional material:

• The information density of the slide is normal at Microsoft (or was in my day) for exec presentations. It complemented a style of discussion that's come to be known as precision questioning. You simply don't have the discussion and decision making flow required if you're trying to drive a particular train of thought through a slide build and flow. This sort of info density is about presenting the maximum amount of related material visually and letting the exec drive the questions. It's amazingly effective if everyone understands the protocol.
• I've not changed any of the wording on the slide or the associated notes. [There's nothing confidential.] Some things may feel dated, and I've certainly evolved and expanded some of my thinking, but I still stand by what I wrote. There are few words I would change today and while I might pick more current examples, these ones were absolutely relevant at the time.

Here's the slide:

Here are the notes I used with the slide:

OSS Development Projects (technology buckets):

Bullet 1 and 3. Good developers develop good software. Good developers have discipline and process. They don’t know how not to have discipline. So version control, CM, design reviews, strong vision communication, automated build management, coding standards, automated test harnesses, bug tracking, peer code review, strong tool support. All understood and published for decades. None of this is attributable to OSS as a development methodology or licensing mechanism. You can think of this in the inverse: of the thousands of OSS projects hosted by SourceForge, why are so few (relatively speaking) noteworthy? (There's also a couple of good papers on how few people actually anchor the few key projects.)

Bullet 3. The projects in the OSS world that matter are anchored by good developers and they're developed using a UNIX development mentality. They have all been developed since the advent of "cheap" networking (at least between the universities and major corporations) through the Internet (email, netnews, and ftp). The Internet enabled the rise of OSS -- not the other way around -- and it was the low-friction medium through which people could share the software. Add a license that requires source code publication and permits libre use of the source code onto the UNIX component model and you have the techno-social movement.

Bullet 4. Examples: the individual contributor to Apache (gives “3” bug fixes but gets back 100s), versus Shell Int’l contributions in a team (code/$$) with management approval to Samba.org (while deeply protecting their own software assets), versus Sun contributing the accessibility features to the gnome desktop in return for a complete desktop for an advanced “UNIX” based desktop.

Bullet 4. People value the work they do differently in different contexts: think of a technical publications person using their writing skills to complete documentation at work, helping their child’s class room complete a writing project in a parent-child project, and writing a sonnet to someone they care for. Same skill set in all three situations, one for money, one as a contribution in community, one as an act of friendship. Or a program manager that spends time on a not-for-profit board in their community using the same skill set they use at work for money.

So what's next?

Applied OSS:

Bullet 3. Msft is an expert here. Publish specs to drive complement value add. Provide certification programs to ensure lots of service providers. Buy, integrate, and bundle. Etc.

OSS Becomes Big Business

Bullet 2. From IBM’s point of view in the product marketing space: every apache installation is a potential customer for Websphere. From a Linux perspective, they are driving home the message that OSS and Linux are the fulfillment of all “our” investments in open systems and open standards, using multiple congruent tactics of OSS participation, standards participation, and patent license management to control the AIX commoditization – which they publicly state is happening – then quickly qualify the remark to a 10 year time frame. With Eclipse, it’s no longer “buy” versus “build” versus “borrow”, it’s “share” to control the java development space and drive complement value add around their world.

Microsoft Starts Codeplex Foundation

Updated [14 Sep 2009, 15:50]: Added a pointer to Andy Updegrove's excellent analysis of his concerns with certain structural aspects of the Codeplex Foundation. It's analysis like this that will keep discussions in the first 100 days lively.

The Codeplex Foundation began on 10 September, 2009, with initial funding from Microsoft. It's mission simply stated "is to enable the exchange of code and understanding among software companies and open source communities."

Today that means:

The Codeplex Foundation provides a framework to facilitate the participation of commercial software developers in open source projects, either through intellectual property contributions to the foundation or through time volunteered under the auspices of the foundation to enable development work on open source projects. The Codeplex Foundation also provides a channel of communication from the open source community back to Foundation partners and other commercial software companies, advancing the dialog between commercial software companies and open source communities.

There's an excellent mini-presentation and voice-over interview with Sam Ramji, the foundation's interim president on SlideShare:

Introducing The CodePlex Foundation

View more presentations from CodePlexFoundation.

The foundation has an interim board of directors (that includes Miguel de Icaza) to take it through the next 100 days, and an advisory board that includes an experience group of people from both outside Microsoft (e.g. Larry Augustin, Aaron Fulkerson, Robert Gobeille, Monty Widenius) and Microsoft employees that continue to do good work in the open source community (Phil Haack, Scott Hanselman, John Lam, Jim Newkirk).

I've agreed to participate as an advisor as well. I believe this is an important step for Microsoft. While there is obvious benefit to Microsoft to continue to participate and develop the open source world with respect to its core revenue streams, there is a lot that can be learned from developing such a foundation in and of itself (as IBM discovered in its own time). There is a gap in the discussion between commercial developers wanting to do more in the open source community and this organization may be in the right position to help foster that discussion. Over time I hope to work with the board and the advisors and contribute as I best can to build that organization.

There's good coverage on a number of channels, some from advisors explaining what they see is the opportunity, some from the press and analysts asking good questions about the future of the foundation:

• Matt Aslett's 451Group commentary.
• Scott Hanselman's (Advisor) blog post.
• Miguel de Icaza's (Director) blog post.
• Bill Staples (Director) blog post.
• Peter Galli's Port25 blog post.
• OpenSource Magazine reportage.
• eWeek article from Daryl Taft.
• InfoWorld article by Paul Krill.
• PCWorld article from Elizabeth Montalbano.
• Andy Updegrove's analysis of the structural aspects of the new foundation.

Microsoft and the Release of Linux Drivers Under the GPL

Microsoft announced that it is releasing a collection of software drivers under the GPLv2 to better enable Linux to run as a first class citizen on their Hyper-V technology. Matt Aslett and Stephen O'Grady provide excellent commentary [as always] and I won't rehash their discussion here.

This is a significant move by Microsoft.

It isn't the first time Microsoft contributed code under the GPL. In the early part of the decade (~2000) the Interix team contributed a reasonable amount of code to the gcc compiler suite that was accepted. We assigned rights of ownership to a Microsoft asset to the FSF as needed. We published the sources as the license required. But that was a different time and a different climate and the last thing Microsoft wanted to do was admit they were contributing to a free software project outside their walls, or that they were shipping software covered by the GPL in a Microsoft product.

Neither is it the first time they've shared their own code. Rob Mensching has been running the Wix project since 2003. That's a project started on SourceForge using a non-Microsoft license (the IBM Common Public License) using a software tool base that is still in significant use inside Microsoft for delivering products.

But then things appeared to shut down from a code perspective. Much of the past five or six years has been Microsoft contributing anything but code. Money to Apache or Eclipse, providing a site where others can contribute code, ensuring third parties make arm's length contributions rather than Microsoft staff, and esoteric contributions such as requesting approval for licenses from the OSI. Their messaging remains guarded. The "position paper" released in March co-incident with the Open Source Business Conference had the same move-to-the-middle ambiguous messages and excuses that began in ~2002 with the Shared Source Initiative. [Misquoting a study to try to demonstrate open source software is still rough and only developer friendly doesn't win them points either.]

The current Linux contribution is significant. It's a significant quantity of code. It's an attempt at direct participation in a major mainstream open source software project to meet business objectives. It should be encouraged. It's an opportunity for the Linux community to embrace-and-extend Microsoft.

As Stephen O'Grady observes at the end of his commentary:

"Microsoft is, this week’s contribution notwithstanding, still holding open source at arms length, in contrast to an IBM who embraces it strategically in certain areas in service of a larger strategy.

But while it is not a conversion, it is important news, a welcome development, and a job well done for those involved. "

The Community Leadership Summit and the Art of Community

Good community leadership is desperately needed. Too often companies mistakenly think of it as some small adjunct to marketing, an extra channel over which to broadcast messages and through which to generate leads. Likewise product engineering can equally confuse community purpose and disrespect its impact, relegating it as "beta tester" or ignoring its contributions with Not-Invented-Here blinders. We've understood community since before we climbed down from the trees, and we've understood the social dynamics: despite our best intents every village has its idiot and every playground has its bully. But when community in its truest collective sense meets business, we seem to forget all our lessons and expect something to manage with the efficiency and efficacy of a time-motion study in an automobile factory.

This weekend, 18-19 July 2009, marks the first Community Leadership Summit in San Jose, California, at the San Jose Convention Centre (McEnery Conf Centre). Jono Bacon, community leader for Ubuntu at Canonical, Ltd. has done amazing work organizing the event and it promises to be a great opportunity to share experiences and learn from one another. It is a free event in front of O'Reilly's Open Source Conference, supported by a small savvy set of vendor sponsors, but the event is about community development experience and not any one vendor's take on it. While free, one should go to the registration page to register.

Jono has also been busy this past year writing "The Art of Community". He developed it over time in conjunction with the Art of Community blog. I was a reviewer, and I think it's an excellent book covering the breadth of the subject. It will be available in August, and you can pre-order it here.

I was hoping to participate in this year's inaugural summit, but unfortunately I'll not be attending it (or OSCON) for several personal reasons. I will certainly miss friends and colleagues, but trust next week will be as brilliant as always!

SourceForge Acquires Ohloh!

First, congratulations to Scott Collison (Ohloh CEO) and the Ohloh team. [Caveat lector: I've been an advisor to them for some time.] It's a great exit for a great little company. As with all the companies I advise, there needs to be something unique going on. Ohloh has always been unique. As I described in January:

When a potential open source user wanted to find out "what open source software is available" to solve a problem, they were invariably left hunting across Google, SourceForge, and sites like java-source.net and FreshMeat. There was no consistency. The depth of information was sketchy. Some of it was bleeding edge software, some tied to the site. There was no sense of "what's good" unless you were already involved in a particular community, and even then community bias could get in the way. This gave way to a collection of directory solutions and companies that tried to bridge this gap.

Ohloh has always had the most useful and interesting directory for me. First, they have no direct sales model tied to the directory, so my trust in the depth and breadth of the information is high. Second, the beauty of the analysis is that the core data is metrics based on what programmers do, not what they say. I can see how big or small a community is, how long it's been around, how active it is, and this provides hard data when one then looks at the qualitative commentary. Third, it's always been comprehensive across the open source world and getting better all the time.

...

Over their several year history, they have continued to expand and add features to their core statistical analysis. They've built the community and expanded the number of repositories they support. Once one finds a project, one can see other projects immediately that are related through the tagging and stacking other Ohloh users share. The site is a proper social network for open source developers. It's been used to get a project manager's view of an open source project by the project's own leadership. As a resource for job hunters and recruiters it's invaluable to be able to see the visual resume of a developer. They've evolved their offerings to act as download host, and provide job and support services classifieds.

In one commentary, Jon Sobel (SourceForge group president of media) made reference to "Another advantage for SourceForge ... is that Ohloh's data will help the company deliver advertising that is more targeted and effective." This is the real key to the acquisition. A primary revenue driver for SourceForge is advertising across the forges and online media properties. Ohloh has been successfully developing a data service that would wildly improve the ability to target technology advertising and provide data rich feedback for high-tech marketing campaigns. [Frankly, Google should have acquired Ohloh.] They have a number of large corporate customers. So through this acquisition:

• Ohloh can improve SourceForge's advertising revenues.
• The Ohloh data service itself provides an excellent additional revenue stream in the high-tech corporate marketing world.
• The Ohloh community site is complementary to SourceForge's forges, providing open source communities better tools for understanding their projects.

This is a great acquisition for SourceForge. Hopefully along the way, the original and unique aspects of the directory that make it so valuable to open source users (as opposed to open source developers) are not destroyed or lost, and that SourceForge continues to recognize the difference between the core data competency Ohloh represents, the core value proposition to SourceForge's customers, and its complementary uses as a separate directory at strengthening the SourceForge brand in non-revenue producing ways.

Other commentary:

• The official press release
• Matt Asay's interview with Jon Sobel, SourceForge group president of media
• Ars Technica Article