Does Conway’s Law Apply to Ansible?

In this post the structure of Ansible will be analyzed. First the structure of the codebase will be discussed. This will be done on the component-level. The most important components will be brought to attention and their mutual coupling will be touched upon. This will be followed up by an in-depth look at the communication and social structure of the development community of Ansible.

With both strucures described, the relation between them will be discussed. The contrast and congruence will be made clear. This will be done in context of Conway’s law. This law states that the structure of a system will reflect the social boundaries of the organisation(s) that produced it, across which communication is deemed difficult.

During the past month Ansible has undergone radical changes in the way its development is managed. This change also influenced the structure of the codebase which in turn changed the degree to which Ansible adheres to the concept of Conway’s law. Therefore the effects of the migration will be explained in the conclusion.

Components coupling

For analyzing the components coupling within the ansible repository, we will look back at our findings in our second essay. Here we looked at the Development View, to understand the relations of the different components in Ansible.

As explained before, most components reside in the modules folder. This is where more than 750 modules¹ are implemented, but they are loosely coupled. Here the module maintainers work on a specific part of the code without bogging down the core code.

However, the core code itself is very tightly coupled. We see this in the bottom four components of the image. These are some of the most important components , and they are mainly maintained by the core development team. As we have discussed earlier, the ansible repository became too large to maintain, which is why the playbooks, roles, plugins, and modules that belong to one platform are migrated to one collection. Later in this essay, we will see how this affects the communication and development components.

Communication developers

Ansible is a very large project with many contributors. It is interesting to know how they organize the communication. In this section we investigate the commmunication structure of Ansible’s developers. Note that we do no talk about other employees of Ansible (such as promotion team) because we aim to investigate whether the code structure and communication structure are mirrored.

Onion model

The community structure of an open-source model can be described with the onion model². In this model, there are three main layers: the core, the semi-core, and the periphery. The core includes the project leaders and the core developers. Contributing developers belong to the semi-core, which can be further divided into active- and peripheral developers, following the definition by Nakakoji et al.³. Lastly, there is the periphery layer that includes the remainder of the open-source community, such as bug fixers and reporters.

Core | The project leader of Ansible is the RedHat company. Here the top-level decisions and future plans for Ansible are made. But the other part of the core layer has an even greater influence on the decisions; the core ansible development team. The core team oversees the total project and directs the total project towards the next release candidate. Following ansible’s github page, there are 62 members of the ansible core team, but examining the pull requests shows a group of 10 active maintainers:

• sivel
• mattclay
• abadger
• jborean93
• relrod
• bcoca
• acozine
• mkrizek
• samccann
• nitzmahone

These members approve, merge, and close pull requests on a daily basis.

Note: there is no official documentation on the core team, the team of active maintainers may be bigger as this list is made by examining a random subset of recent pull requests

In the code base as it was before the “migration” (see our previous essay), this core team was responsible for reviewing all pull requests. As the pull request backlog of ansible was increasing, these reviews became more and more just an approval or disapproval after a module maintainer had already reviewed the code. Since the migration, the responsibility of merging the new code now lies completely with the collection maintainers.

It is not entirely clear how the core team communicates. Ansible has many IRC channels on Freenode. The ‘problem’ with Freenode is that we cannot trace back communication history. If a user goes offline and online again, he or she will not be albe to see communications that he or she missed. Anisble’s core team also does not have location where they work together in the same office. For example, core team member Abadger is location in California, US while Akasurde works from Maharashtra, India. Red Hat has many offices all around the world. Additionally, it seems that the core team have private communication channels. After doing an extensive research, we have not managed to find out how many private channels there are and what sort decisions are made there.

Semi-core | This brings us to the semi-core layer; consisting of active- and peripheral developers. The active developers are the collection maintainers. They have full responsibility for their collection, but will follow and adjust to the decisions made by the core team. The collection maintainers lead working groups that work on a specific part of ansible. Such as the community.windows working group. On their github wiki page, we see a list of 8 collection maintainers. Two of them are part of the core team as they are employed by Red Hat. It can be concluded that the core team operate both in the core layer as in the in the semi-core layer.

Ansible has many working groups. The figure above shows which members of the core team (rows) are active in a specific working group (columns). Note that these are only the working groups that work on the ‘system’ component of Ansible. Green indicates that the member is either a leader or a reviewer in that group. Every working group has its own meeting schedule on Freenode. Also note that bcoca is active in many working groups. This indicates that there is also an hierachy within the core team.

People that work on a collection but are not maintainers, are the peripheral developers. They implement features that are decided on by the maintainers. However, the peripheral developers can participate in the decision making and the working group as a whole sets out the future plans. The working group wiki holds a list of ideas and a progress tracker.

Periphery | Lastly, the outer layer of the “open-source onion” consists of the remaining members of the ansible community that do not make any big decisions or are responsible for any part. A large part of this layer is made up of bug reporters. The bug reporters are mainly the users of ansible, that come across bugs while writing their playbooks. They fill in the issue template in the corresponding part of the ansible or ansible-collections repository, with the file in question and steps to reproduce the bug. These bugs are then picked up and fixed by peripheral developers of the corresponding collection or by bug fixers in the peripheral layer, that incidentally fix bugs.

This layer communicates mostly through PRs. Ansible is well-documented and not much communication is needed with the core team. The communication relationship between this layer and the semi-core layer is a ‘A reports to B’ relationship. Developers in this layer do not have much authority and every proposal has to be approved.

Contrast code and community

In section 2 we saw that some core team members are active in many groups. This limits opportunities and as uncertainty increases, the amount of information that must be processed by decision makers also increases. This forms a bottleneck for the development of Ansible, which can lead to pressure to meet the deadlines for releases. This pressure can for example lead to increased technical debt or burnouts of the team members. This can be very harmful, since Ansible heavily relies on its core team.

Ansible must have been aware of this danger and decided to act upon it. We see in this blog post that the migration is meant to remove the core maintainers (which mainly consists of core team members) as a bottleneck to the community module and plugin development.

Looking at this from the perspective of Conway’s law, one can conclude that the codebase did not match the organisation structure. To be more precise, the division of the development community in so-called “working groups” was not reflected back in the codebase. What happened in the migration is that from the perspective of the codebase a clearer distinction was created between the core code and the collections. The relation between the core code and the collections now very accurately matches the relation between the core team and the working groups, that consist of contributors.