KiCad - A Technical and Sociological comparison

Welcome back to yet another blogpost that’s all about the KiCad EDA. Unfortunately this will be the last blog from this series and if you have not yet read our previous blogs, you should! In this week’s blog we are going to take a look at Conway’s law and socio-technical congruence. The KiCad program gives you the opportunity to design schematics and printed circuit boards and generate the files to have them fabricated. First we will explain the law and the term Socio-Technical congruence. Then we dive into the coupling between components inside KiCad and take an in-depth look at the communication and social structure of the KiCad development community.

It is beneficial, but not necessary, to read our second and third blogpost before continuing. In our second blogpost we explored KiCad with different architectural views, which might be useful to get a better understanding of the coupling of files that will be discussed later on. Besides that, the third essay assessed the overall quality process and quality culture of KiCad which can be used to gain extra insights during the discussion of the communication and social structure.

KiCad in a socio-technical view

More than half a century ago a computer programmer, Melvin E. Conway, stated the following:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

— Melvin E. Conway¹

This principle can be observed in multiple large companies such as the ones shown in the figure² below. When designing and developing a project, which could be of any kind, it is impossible to have everyone communicate with everyone. This would result in a massive communication overhead. Instead it is more efficient to divide the project into components that have technical dependencies between them.

According to Conway’s law¹ the component structure and organizational structure stand in a homomorphic relation with each other. To put this into a more clear perspective, teams are allowed to work on multiple components of a system, however, no more than one team should be assigned to a component.

Socio-technical congruence

Every software project which is being developed, has besides the technical component, also another very important aspect, the social component. This element is as important, if not more, than the technical component. At the beginning of a project the coordination of how project progress will proceed, while maintaining quality and good communication between different project components, has to be done.

Preceding to this is carrying out these ‘rules’ by the organization. Certain aspects that come to light in a project under development will now be discussed³. Such an aspect could be the evolution of the system’s requirements, these include but are not limited to, adding of new features, updating old features, improvement of documentation.

Another aspect is the dynamic nature of dependencies. These could conclude data-related dependencies or functional dependencies. Data-related dependency happens when certain data is modified by a function and used by another one. A functional dependency is when an application or function calls another application or function.

In order to analyse the productivity of an implementation of a certain socio-technical congruence, certain productivity measures can be used. These could include the resolution time of merge requests (hereafter MR). However, these have to be scaled since people could be working on multiple MRs simultaneously or a MR could be put on hold since another one got a higher priority. Task reassignments can also have a large impact on the project’s development time.

Taking into account these aspects one can take a look at the technical structure and the communication structure. Research showed that higher productivity is achieved when the coordination needs are fulfilled by the communication structure. Ultimately, this means that it is positive if there are similarities between the technical structure and the communication/coordination structure. This relationship is meant when you use the term socio-technical congruence³. So let’s first take a look at the technical structure in the next section and thereafter we will investigate the communication between contributors.

Components Coupling

KiCad is split into multiple parts: KiCad(file manager), Eeschema, Pcbnew and a few smaller and lesser used applications. To get more insight in the architecture of KiCad, you can read our second essay. These are obviously coupled together because they all use some parts, like the tools and toolmanager, but also the rendering(OpenGL, Cairo and WxWidgets) are parts that they all share. We used Codescene.io to analyze the KiCad source code and a few remarking things came up. Codescene ranked the source code a 2.73 out of 10(3.80 last year), this shows that it is not a perfect codebase, but it is also not striking that it isn’t a 10, because C(++) projects are more prone to getting messy than Java projects for example.

The next figure shows the coupling between different files based on the commits of the last year. The red lines show increasing coupling, yellow stable and blue means decreased coupling.

Some parts are little islands of coupling. One that is very visible is the red one at the top, this is all code of plotting schematics to files, like svg, photoshop or pdf. It is tightly coupled, because they all do almost the same thing and therefore have a lot in common and are coupled together.

Another island with few incoming/outgoing edges is the red part in the bottom right. These components all belong to the Design Rules Checking (DRC) testing functionality. DRC checks the rules set by a designer or pcb factory, like minimum width of a trace or no crossing traces. They all do a part of the rules and therefore are also coupled together.

A file that is coupled with a lot of other files is the toolbars_sch_editor.cpp and this file has a function that adds all of the buttons and actions corresponding to them to the window. This makes it obvious that it has a lot of coupling, not only within its own part, but also with other parts of the code base.

Overall, we can say and see that there are some parts that are coupled very tightly with each other, but there are also a lot of parts that are coupled very tightly with different parts of the application. Of course a bit of coupling is needed to have the components work together, like it is to have a nice working car instead of a crate full of bolts, wires and steel parts. Too much coupling on the other hand is also not wanted, because this would mean that when a component is changed slightly, a lot of other components also need changes to work again with the changed component. This can be compared to when changing normal car tires for snow tires, the rear axle also needs to be swapped, because they are tightly coupled in some way.

Communication

We have analyzed the repository using CodeScene and found that 95% of the code is written by 31 developers. Though this is not a very large number for a project of this size, it is still challenging to manage communication and coordination in a team of this size, especially since most of the contributors are volunteers.

To analyze the coordination requirements we have used another tool that CodeScene offers which indicates the coordination requirements for all files. This is calculated using the number of different authors and how much the code is distributed among these authors. In this plot we can see that pcbnew and eeschema require the most coordination, which matches with our findings of the code hotspots in our last post.

To find the communication structure within the KiCad development community we have used the GitLab API to retrieve all comments on merge requests in the past two years (since KiCad started using GitLab). The code is available here . We have processed these comments to calculate how often each pair of two developers reply to the same merge request, and thus discuss with each other. Then we visualised this data as a graph where each node is a comment author and the links between nodes represent interaction between them. The thicker the link the more interactions happened. To reduce clutter we left out links below a certain threshold of interactions. The layout of the graph is determined by a physics simulation where each link acts as a spring. An interactive version of the visualisation is available here, the nodes can be dragged to rearrange the graph and explore its topology.

In this graph we can see that the main maintainers, which are indicated by colored nodes, all communicate with each other a lot, in a tight clique. Around them we see a group of contributors that interact with most or all of the maintainers regularly. On the left we see two of the main maintainers that handle a large part of the communication with less regular contributors, Seth Hillbrand (red) and Ian McInerney (green). This allows the project lead, Wayne Stambaugh (yellow), to focus on communication within the group of maintainers and active contributors.

Back to Conway and socio-technical congruence

The second section has made clear that some parts consist of tight coupling, such as DRC and that some parts, such as _toolbars_sch_editor.cpp, _have tight coupling over multiple files/components since it combines all of the buttons and actions to the corresponding window. As mentioned too, we saw that the tools and tool managers have coupling, even across the Pcbnew and Eeschema applications. The same applies for some rendering parts like OpenGL and WxWidgets. Thus, there are clearly (highly) coupled parts that are loosely coupled to other parts in the codebase.

The communication research revealed that there is no clear division of groups or responsibilities to be seen in the communication on github. One of the reasons is the method of peer reviewing. Often several developers are involved in checking or debugging improvements or new features, for example because they use different operating systems. They obviously have to communicate the results to each other. However, testing the code is somewhat separate from the responsibility of fixing or improving the code. Therefore, this communication contributes to a reduced understanding of the structure of communication; unfortunately, it was not possible to filter out this interaction between developers.

Another reason is that (lead) developers are not systematically assigned to MRs that deal with the same parts of the codebase.

As a result we do not see a homomorphic relation between component structure and organizational structure. However, we could also not find strong evidence to confirm or disprove Conway’s law. This is because the communication does not show any signs of a structure. In our opinion this is due to KiCad being an open-source project that is very welcoming to everyone. The KiCad project is very open to everyone’s insights and opinions, so decisions are well thought-out but also take more time. Moreover, due to many volunteers working only in their spare time, KiCad is more likely (and heavily) to be impacted by a changing group of developers and their varying input than companies would have. This makes it more difficult to distribute components evenly and clearly. To conclude, the socio-technical congruence in the KiCad project is vague but difficult to improve.

Some final words

We would like to thank all readers for their interest in our blogs. We have enjoyed working on the blogs with the aim of introducing others to various software architectural relevant topics and of course KiCad. We hope you enjoyed it as much as we did! Furthermore we would like to express our thanks to all the people involved in the KiCad project. It is the developer community, from small to large contributors, who make sure that more and more people worldwide can use (free of charge) software that contributes to the development of new products for society. Finally, we would also like to thank Arie van Deursen and Diomidis Spinellis for this opportunity, their help and the transfer of knowledge needed to research this open-source project.

Stay safe and keep developing yourself (and PCB’s)!