When Enterprise meets FOSS

If 2008 had a buzzword, it was probably community. More and more companies are looking to tap into communities for contributions to open source projects. But following the open-source trend just because everyone is doing it isn't good enough. To succeed, you need a well-thought-out community plan that details exactly what your organization needs and wants from its community, and how it can achieve those goals. And you need to do so without raising the ire of the free and open-source software (FOSS) community.
##CONTINUE##
The point of insisting on FOSS project metrics isn't to discourage enterprise open-source involvement -- quite the opposite. Organizations can plan for success early on by planning to measure contributions up front. This means setting goals from the start, and then designing a roadmap to get you there. Too many organizations begin with poorly-defined or vague goals (such as "build community"), and wind up disappointed with the results. Then they blame the open-source model. In reality, that's a failure of leadership and clear direction-setting.

What to Expect

Companies looking to invest in community contributions should be aware that it takes time to reap returns on the investment. Throwing code over the wall isn't sufficient to get contributions. Developers need to interact with the community to help support their efforts. It usually takes time for outside contributors to learn their way around a project and to become productive.

If the goal is to "outsource" the majority of development to the open source community, forget it. While a healthy community can provide valuable contributions to company-sponsored open source projects, it is not a substitute for an engineering staff. Contributors also expect some voice in the direction of the project itself, and reasonable governance of the project.

If this sounds like a lot of limitations, the flip-side is that healthy communities do contribute a great deal to projects, particularly in terms of testing, patches, translations, new features and help in marketing the open source project. Evans Data research about open source developer trends regularly demonstrates that about two thirds of developers who change source code contribute back to the community.

What kind of contributions?

Before your company launches an open-source project, you should decide what kind of community it wants to see flourish and determine the nature of contributions the business desires. Do you want a massive user community, but you aren't too worried about code contributions? Or is it better for you to have a small developer community that dedicates its developers' time to working on the open-source project that most benefits the corporate goals?

Another option is a developer community that uses and extends the technology, such as SugarCRM, which has a healthy contributor community creating extensions to the technology. Contributions come in many flavors and types, and one size doesn't fit all.

Some companies are content with "source open" projects-that is, projects that are available under an open-source license, but with the vast majority of development done by in-house developers. In this case, you can measure your organization's success by adoption alone.

But once you know what you want... how do you learn if you're achieving it?

How to measure success

Downloads are a pretty lossy metric, given that a lot of downloaded applications are never installed. There are several way to approach, if not get, accurate data. You might want a way to track product updates or installations. For instance, a program can "phone home" once after it's installed (with the user's consent, of course). One example is Smolt, initially developed by the Fedora Project, and now also being used by the openSUSE Project. (Smolt does much more than track the number of installations. It gathers hardware profiles to help identify what hardware is most commonly used on Linux systems.)

Another metric to consider is the number of users. For example, the openSUSE Build Service requires developers to sign up for an account to create packages. That lets us track the number of developers who signed up, the number of packages in the system and how many projects are underway.

It's important to think through your tracking system at the outset, as retrofitting can be difficult. For instance, if your bug tracker doesn't distinguish between your organization's employees and community contributors, how can you identify the number of bugs reported externally versus internally? Tracking "bugs reported" or "bugs resolved" is not a very useful statistic if you're not sure who's doing what.

And, of course, you have to encourage success. If code contributions are the goal in your company, for instance, a lightweight and liberal copyright assignment policy is more likely to encourage contributions. Requiring contributors to assign all rights to your organization is probably not going to inspire developers to work with you. Yet, having no copyright assignment policy at all may make it difficult if your organization wants to make changes down the road, such as switch from one open-source license to another.

By setting clear objectives from the outset, it's easier for your company to determine whether open source is the right path for your software development project. Once the decision is made, work the plan and adjust as needed to get to the desired results.

-----------------------------
BY Joe Brockmeier
Source：JAVAWORLD

Joe 'Zonker' Brockmeier is the openSUSE Community Manager.