Bridging the gap between companies and communities for OSS

In a presentation at the Southern California Linux Expo (SCALE), GNOME Foundation executive director Stormy Peters discussed the differences between companies and communities and how to bridge the gap. This issue is becoming increasingly important for open source software projects that are trying to build close ties with corporate adopters and contributors.

Peters developed extensive expertise in this area during her time at HP, where she played a central role in establishing the company's open source program. In her current position as the head honcho of the GNOME Foundation—the non-profit organization behind the open source GNOME desktop environment—she works to build bridges between the development community and the growing roster of companies that participate in the vibrant GNOME ecosystem.

The underlying premise of her presentation is that open source software communities and the companies that leverage open source software are interdependent and need to cultivate sustainable relationships in order to advance their mutual goals. This effort is often impeded by conflicts between corporate and community culture. Peters explained many of these conflicts and described how companies can benefit from adopting certain aspects of open source culture.

She laid out some of these ideas in a blog post earlier this month and invited feedback while she was preparing for her SCALE talk.

"The goal should be for companies and individuals who use and support open source software to work effectively together. And part of working effectively together means making sure that the open source model is sustainable. Which means interacting for the good of the project, not just taking or using open source software," she wrote.

Open source culture

There are numerous factors that contribute to the success of open source software. Passion, she says, is one of the key factors that drives development. Voluntary open source development is often self-motivated and conducted without need for management. Schedules are fluid and people work as needed to complete their own desired goals.

The collaborative development process has built-in peer review and ensures that developers receive constant feedback. Peters comments that there is an important distinction between the kind of peer review that is inherent in open development and the kind of performance evaluations that are common to corporate environments. In an open source project, the quality of code is judged as it is written and is constantly improved or rejected as needed to produce a better product.

Why don't companies get it?

Peters contends that companies are less trusting of employees because employees are more likely to be motivated by the desire for monetary compensation rather than personal commitment to the company's projects. This creates a less team-oriented atmosphere. She says that companies are also hesitant to adopt meritocracy—which is one of the core values of community-driven development—because they are afraid of the changes that it will bring to management structure. This could potentially be mitigated, she suggests, by peer-based systems in which groups organically choose their own leaders.

Transparency is also difficult in a corporate environment, Peters says, partly because so many companies are afraid that transparency heightens the risk of disclosing trade secrets. She believes that these fears are largely unwarranted and that trade secrets, as a result of the fast pace at which industry evolves, don't provide as compelling an advantage as they once did.

Another important aspect of transparency is internal communication. The distributed nature of open source development generally encourages robust interaction and highly transparent communication. She believes that face-to-face interaction often makes people communicate in a way that is lazy and not conducive to transparency. As an example of this, she explains that when coworkers are just a cubicle away and easily available for quick questions, people tend to be less inclined to document and discuss details in venues that are broadly accessible to everyone who is participating on a project. This problem can be addressed by making company wikis and mailing lists the preferred mediums for work-related interaction.

Boosting transparency and moving towards self-governance could help companies benefit from some of the values of the open source development model and could also help companies improve relations with open source software communities. As companies become more tightly integrated with the open source ecosystem, these cultural changes will help build bridges and facilitate more productive relationships.

Listing image by Ville Miettinen