Git: https://github.com/miekg/dns
Introduction
History/Purpose/Goals
Miekg/dns is a go library to simplify the development of DNS servers and clients in Golang. It is used by many high-profile companies including Cloudflare, Baidu, Slack, and Hashicorp.
First Commit/Most Recent Commit
The most recent commit was merged on March 19, 2023, and the first commit was on Aug 3, 2010.
Leadership and Team Structure
Lead Developer
The project lead is Miek Gieben, who used to work as an SRE for Borg at Google. He has also authored two RFCs about DNS (7719, 6781). He also maintains CoreDNS, which was built on this library, and is now a Linux Foundation project. Miek accounts for a large percentage of the commits, (3,091 commits at 658,085 lines).
Core Team
While Miek accounts for many of the commits, there are a couple of other contributors. Typically, you see smaller commits with many more lines in these other contributors. For example, Tom Thorogood only has 181 commits, but has 248,166 lines committed. Three other contributors have over 1000 lines of commits each, and there are dozens with hundreds of lines. It is difficult to make perfect judgements, since for a time, source code for dependencies were included in the repository. They are no longer included.
Unique Knowledge
Miek has by far the most unique knowledge. He has been involved with the project for over a decade, and accounts for much of the major development. If the top 20% of contributors died, it would be very unstable. However, there would be tremendous pressure to stabilize the project. This is because if the project is not maintained, the internet would experience severe disruption. Cloudflare and the Linux Foundation would be the most obvious organizations to step in. Cloudflare cannot exist without this library, and while they may not contribute significantly themselves right now, they would have tremendous incentive to support it.
Commit Access
Anyone can file a pull request to have it merged into the project. It must be approved by Miek or Tom.
Quality Control and Bug Repair
Miek and Tom take responsibility for the quality of the project. Anyone can fix bugs and issue a PR. However, the maintainers will work to make sure that the PRs are up to their standards. Significant bugs are likely to be resolved directly by Miek and Tom. There is no responsible security disclosure policy.
Front End/Back End
This consists of only a back-end, as it is a DNS resolver. Front ends are developed by third parties. The most notable third party interface is Cloudflare.
Stability
Calloway Coefficient of Fail
The project has a Calloway score of 35 (“Babies cry when your code is downloaded”).
+10: Does not build with GNU Make
+10: No mailing list
+10: No per-file licensing
+5: No releases announced on a mailing list
Major Bugs
The code is generally well-designed and well-written. There have not been any significant bugs during the development process. Major bugs should be reported to the issues board. There is no private or responsible disclosure method for security vulnerabilities.
Participation Trends
Based on data in Cauldron, participation is highly volatile, with massive swings in contributions week-by-week. There is no clear pattern to commit cycles. The library is highly stable, and there are no major changes happening at this time. While it does stay up to date with the bleeding edge of IETF standards, IETF standards do not move quickly. The closest correlation that we could find is that there is a somewhat strong correlation between commit cycles and go releases. This could suggest that much of the current development work is modernizing the library as go evolves. There are many smaller contributors, who in total account for a large proportion of development, but individually have very small contributions.
BDFL Git-by-a-Bus
If Miek could not continue contributing to the project, it would suffer. Tom would have to take control and stabilize it. It could require intervention from a corporation to invest resources.
Core 20% Git-by-a-Bus
If Miek and Tom could no longer contribute to the project, it would severely suffer. However, there would be tremendous pressure to have an organization take control of the project. Given how stable it is, and that it is statically linked into other projects, there is little risk of things going wrong in the short term. However, if the library broke and nobody could contribute to the project, the results would be catastrophic. It could lead to substantial swaths of the internet going offline.
Onboarding and Support
Onboarding Process
There are some fantastic and simple examples for developers to integrate the library for their software. A developer could easily implement Most users will be reliant on a third party application that includes the library, and so that responsibility would lay with the application developer.
Documentation
The documentation is standard for golang projects. It is not exceptionally detailed by any means, but it is well within the standards of organizations like Google.
Contributing
The project welcomes new contributors, and many people make small contributions to the project. There is not a super vibrant community around it, and not a lot of guidance to contribute if someone needs help.
Code of Conduct/CLA
There is no explicit CLA.
Summing Up
Decision-Making Structure
Decision making is subject to community feedback, but is ultimately made by Miek and Tom. There is a clear and well-articulated set of principles for the library, meaning that the decision making is usually clearly based on principles. Most of the high-level decisions are determined by IETF standards, given the project’s commitment to follow the latest IETF standards.
Toy? Stadium? Club?
This project is very difficult to categorize into traditional Open Source categories. It started out as a toy, and still has elements of the toy today. There are also some elements of a club (a wide set of small contributors) and a stadium (high centralization of ultimate decision making). It is very difficult to categorize because of the project’s history. While it started out as a toy, it has an outsized impact relative to other toys. Given these constraints, we think that it is best considered a club. There is a small but vibrant developer community, and organizationally it is most similar to a club. The scale of non-contributing dependents is the biggest factor against being a club, though they are non-contributing due to their own choices, rather than exclusion from the project.
Should Someone Contribute?
People are welcome to contribute, and there are many active issues available. However, there may be limited support and code must be well-tested. There is substantial risk if a PR introduces breaking changes, and so PRs are subject to immense scrutiny. Novices should be reasonably familiar with IETF DNS standards and Go before making any substantive changes.
Cauldron Analysis
We used Cauldron to look at commit and author trends. We see a healthy mix of new and returning contributors, both to pull requests and issues. There was a large break in merges between June and November of 2022, due to no go versions released and no issues pending.
Alex Beaver