On the 23rd of October, Gitlab users received a message explaining that the Terms of Service were updated so that the enterprise edition of Gitlab would contain telemetry. In plain English, this means that Gitlab Inc. would collect unspecified data from how companies use their enterprise edition of Gitlab and might send it to third parties of their choice. Developers were not amused and, in true open-source fashion, jointly proposed to turn this into an opt-in.

The CFO of Gitlab, Paul Machle, did not understand. Surely Terms of Service are not subject to opt-in or opt-out? If you want to use the product, accept the ToS.

Developers responded in very colorful ways and started leaving the Gitlab community. One week after the email of 23rd October, Gitlab Inc. rolled back the change in ToS.

What happened? Essentially, Gitlab made a blunder in ecosystem governance. They mistook the Gitlab community for a business that offers a product to its customers. To see why this is mistake, we need to understand the difference between relational and hierarchical governance.

What is governance?

“Governance” is a vague term that does not appeal to software engineers. Some definitions of it are nearly incomprehensible. I offer this definition to the techies among you: Governance consists of

  • decisions about who is part of a community and
  • decisions about the continuation of the community.

For example, in a neighborhood community, decisions about who is a member are made by the people who move into or out of the community.

Continuation decisions are decisions about the survival and well-being of the community. These decisions are made by the neighborhood members themselves but also by local government. For example, the community members may all decide to move away, or alternatively to breathe life in the community by organizing joint activities. Local government can allocate budget to maintain the community infrastructure, etc.

Relational and hierarchical coordination

Governance decisions are coordination decisions. They are about how a set of actors coordinate their activities in a context of shared and finite resources.

Sociologists distinguish three coordination paradigms, of which for the Gitlab story two are relevant.

  • In relational governance, actors coordinate their actions by shared norms and values. Trust is crucial. Becoming a member of a relational community takes time and effort because you must earn the trust of the other community members. You must show that you contribute to the community according to its shared norms and values. Examples of relational communities are communities of open source developers, neighborhood communities, and scientific research communities.
  • In hierarchical governance, governance is done by management who bears the final responsibility for decisions. Hierarchical communities are organizations with a central management. You become a member by being hired and then have an employment contract that states your roles and responsibilities in the organization.

Clearly, the CFO of Gitlab Inc., Paul Machle, mistook the Gitlab community for a hierarchically governed business where C-level management has the final responsibility for decisions about the product and its terms of service.

But there is more.

Decisions about entry and exit in a community

Governance also consists of decisions about entry and exit of a community. In a relational community, anyone can decide to join. Community members will gain trust in new members based on their contribution to the community. In a hierarchical community, by contrast, entry and exit is by hiring and firing an employee.

The Gitlab developers are, by definition, also Gitlab users. Gitlab is itself maintained in Gitlab. If the Gitlab community would have been a business with employees, and the employees would have used Gitlab to develop Gitlab, then Gitlab employees would have been Gitlab users too. But as users they would have had no say about the Terms of Service of the Gitlab system. Management would decide about that.

But Gitlab is an Open Source system with a developers’ community that is governed relationally. The developers-users jointly decide about functionality such as collection of telemetry data. They are free to leave the community if they wish and start a new community. Opt-in and opt-out of these functions are not simply management decisions, but community decisions.

Being a distributed company

According to his Linkedin account, Paul Machle was previously employed at businesses whose employees work in a building. Working in the same building greatly facilitates the development of a shared culture. The Gitlab development community, by contrast, is distributed. Members do not meet each other physically but online. As acknowledged by Gitlab, this may hamper the development of a shared culture.

Gitlab Inc. is a commercial business built on top of the Gitlab developers’ community. It provides value-added services to enterprises on top of the community edition of Gitlab. The telemetry blunder of Gitlab Inc. shows that C-level executives of such a company need a thorough introduction in the values of the community on which they depend.