Skip to content
team banzai

tech demo · investment / m&a

Reading a company's code before you buy it

Eleven famous software deals, examined on the eve of their acquisition or licence change with a single source, the commit history, without letting in one piece of data later than the signing.

A tech due diligence is the examination of a company's software before buying it: what is there, what state it is in and who it depends on. The buyer cares because the price of the deal rests on that software, and because the problems nobody sees at signing get paid for afterwards.

The idea behind this demo: a software's change history can be audited like a set of accounting books. Every serious program lives in a repository, the archive holding the code with its whole history; each entry in that history is a commit: one concrete change, with its author, its date and its email. Nobody writes those entries with an audit in mind, and that is why they tell the truth: who works, how much, for which company and since when.

The conclusion, up front: the git tells you far more than you think on the eve of a deal, but not everything, and we know exactly which part it does not tell you. The detail is in the map and the cases below.

Here the object is code, but the logic, squeezing the trail a business leaves without meaning to so you know what you are buying before you sign, is that of any due diligence: payrolls, contracts and delivery notes tell their truth just like commits do.

the case file as of the eve · commit date

11

eves examined, from OpenOffice 2009 to Redis 2024

6

signals with a sealed formula, from the git history alone

24

months after the event, labelled with another sealed formula

When a company is bought, the accounts get weeks of auditing. The software the business runs on, quite often, a glance. And the question that matters on the eve of signing is not whether the code works today: it is how many hands it depends on, how many companies, and what will happen to them when the owner changes.

The cases are famous and we know how they ended: this is no blind prediction. What was frozen before looking is the definition of each signal, formula included, and the computation is mechanical: anyone can run the same script on the same repo at the same date and get the same number.

The premises, sealed before looking

Before computing a single number we wrote down what we expected to find and the rules we would measure it with. It is the difference between an exam and a story told with hindsight: if a premise fails, it cannot be retouched.

premise 1

Projects that depend on a single company and few hands end badly.

If almost all the code is written by people from one company, and there are few of them besides, the project sits at the mercy of that company's decisions. It is the risk corner of the map.

premise 2

Commercial drama does not soil good code.

Projects with a healthy substrate survive acquisitions and licence fights: the headline scares, but the daily work goes on. Separating technical truth from the commercial decision should be possible and measurable.

the method's commitment

Rules and thresholds frozen before computing.

Formulas, cutoff dates and thresholds were fixed in a public pre-registration before looking at a single piece of data. Whatever comes out wrong gets published anyway, caveat included.

pre-registration · commit 15bcb3a

What the system sees and what it has covered up

Each project is examined at a cutoff date: the exact eve of its event. The six signals can only look backwards from that day, over 12 and 24 month windows. Everything that happened afterwards stays covered; it is only uncovered at the end, to label how each case ended.

the cutoff date commit date · not one later data point

PAST · what the exam sees FUTURE · covered for the exam cutoff date: the eve of the event the event (the deal or the licence change) is the next day 24 months back: each company's weight 12 months: hands, pace, new faces event + 24 months: only to label how it ended
The signals are computed with the commit date (when each change was recorded) and not one data point later than the cutoff. The final label (DEGRADED, STABLE or THRIVES) does look at the future, on purpose: it is the marking of the exam, not part of it.

The six questions every repo gets asked

Each signal answers a question any buyer understands, with a formula fixed in advance over the commit history.

S1How many people does it depend on?

The bus factor: how many authors you would have to remove to lose more than half of the past year's work.

S2How many companies does it depend on?

The email domain of each commit says which company the work comes from, and how much the biggest contributor weighs.

S3Speeding up or braking?

The trend of commits per month over the past year: whether the project is gaining pace or losing it.

S4Are new people coming in?

How many new faces have joined the author core over the past two years, and how old that core is.

S5Does it ship releases?

The release cadence: whether it publishes versions regularly right up to the eve or has gone months without shipping.

S6How much history does it have?

Age, total commits and authors. Not an alarm: it is the context for reading the other five.

How we do it

  • Each project is examined on the exact eve of its event (acquisition or licence change), with committer date, and not one data point later than the cutoff.
  • What happened afterwards is labelled at event plus 24 months with a formula that is sealed too: how much pace the original keeps, how many of the top 5 authors stay, and whether a fork overtakes it. DEGRADED, STABLE or THRIVES, no manual exceptions.
  • Everything was sealed in a pre-registration before computing a single signal commit 15bcb3a.
  • Before trusting a figure, manual inspection: repos imported from other systems lie if you do not look. In MySQL, two signals are reported as not cleanly computable instead of a pretty number.

The result: eleven eves on one plane

Each dot is a project on the eve of its critical moment, placed by what its git said that day. The further right, the more it depended on a single company. The further down, the fewer hands. The colour says how it ended: the red ones ended badly, the teal ones thrived, the grey ones landed in between.

If premise 1 were exact, every red dot would sit in the bottom right. Hover over a dot or tap it to read its case file.

the map of the 11 cases pre-registration 15bcb3a · label at event+24m

OpenOffice

DEGRADED Oracle buys Sun · 2009

top domain 98.8% · bus factor 4 · technical

On the eve of Oracle buying Sun, 98.8% of the past year's commits came from a single domain. A textbook monoculture: almost everything was written by people from one company. A year later the LibreOffice fork was born and took the development with it.

its caveat By activity and renewal it looked healthy: on the rise, and bringing new faces into the core. The only signal that saw the risk was the single-sponsor one.

Axes and labels fixed in the pre-registration before computing. Each case has its report with the commands to reproduce the exact number. The shaded zone (top domain above ~70%) is the single sponsor; the bus factor 2 line is the classic threshold from the literature. Orientation only: v0 does not score.
The eleven case files, as text (no mouse needed)

  • OpenOffice · Oracle buys Sun · 2009 · degraded · top domain 98.8% · bus factor 4 · technical

    On the eve of Oracle buying Sun, 98.8% of the past year's commits came from a single domain. A textbook monoculture: almost everything was written by people from one company. A year later the LibreOffice fork was born and took the development with it.

    its caveat By activity and renewal it looked healthy: on the rise, and bringing new faces into the core. The only signal that saw the risk was the single-sponsor one.

  • PostgreSQL · healthy control, same 2009 cutoff · thrives · top domain 42.6% · bus factor 2 · control

    The control twin: Tom Lane signed 42.6% of the commits by himself and the bus factor was 2. The people signal, read on its own, would have screamed danger about the project that is still alive and healthy today.

    its caveat Its top domain is not a company: it is Lane's personal machine. Behind it sat 12 independent organisations, the opposite of a monoculture.

  • Travis CI · Idera (private equity) buys it · 2019 · degraded · top domain 16.3% · bus factor 4 · mixed

    Bought by a private equity firm in January 2019; weeks later much of the technical team walked out. At 24 months the main repo ran at 43% of its pace and only 2 of the top 5 authors were still around.

    its caveat Its 16.3% on the X axis is a floor: the team committed with personal email and the domain lens cannot see the sponsor who paid almost every salary.

  • MySQL · Oracle buys Sun · 2009 · thrives · top domain 54.3% · bus factor 10 · commercial

    Same buyer and same day as OpenOffice, opposite outcome: the original sped up (D1 1.40) and 4 of the 5 core authors stayed on. The media noise around the deal did not fool the mechanical label.

    its caveat Its history was imported from another version control system: the 54.3% is a manual recovery and two signals are reported as not cleanly computable.

  • nginx · F5 buys Nginx Inc · 2019 · thrives · top domain 45.5% · bus factor 1 · commercial

    The worst possible bus factor: 1. Maxim Dounin signed 56.8% of the past year by himself. And after the deal the project nearly doubled its pace (D1 1.94) with the whole core in place (5 of 5).

    its caveat The 45.5% is the script's raw number; with outside context (Dounin on the payroll), around 91% came from a single company. And years later, outside the window, Dounin broke with F5.

  • Terraform · licence change to BSL · 2023 · stable · top domain 16.5% · bus factor 5 · mixed

    On the eve of the BSL change, a healthy substrate: bus factor 5, 154 authors a year, weekly releases. The OpenTofu fork did not dethrone it: a tie at 89 commits in month 24.

    its caveat Another floor on the X axis: most of the core was on HashiCorp's payroll and committed with personal email.

  • Redis · licence change to SSPL/RSAL · 2024 · degraded · top domain 24.6% · bus factor 5 · mixed

    Healthy on all six signals: many hands, diverse, active, renewing itself. And it degraded anyway: the core left almost entirely (1 of 5 stayed) and the Valkey fork overtook it within two years. Those who left did not leave the project: they left the owner.

    its caveat Its risk was legal control of the licence, in the hands of the brand owner with ~21% of the code. That is not in the git.

  • Atom · Microsoft buys GitHub · 2018 · degraded · top domain 45.7% · bus factor 4 · commercial

    The new owner already had another editor at home. At 24 months the pace had fallen to 47%: death by business decision, not by the code.

    its caveat Its D1 of 0.47 grazes the threshold (0.5) and the team kept committing (5 of 5). The actual archiving came in 2022, outside the sealed window.

  • npm · GitHub buys npm · 2020 · stable · top domain 21.4% · bus factor 1 · commercial

    Bus factor 1 and braking on the eve. The buyer replaced the hands: a new team and activity multiplied by 2.4. The fragility was real; the relief came from outside.

    its caveat It stays at STABLE because two of the five core authors stopped committing after the deal: the sealed rule asked for 4 of 5 and only 3 stayed.

  • Docker/moby · sale of Docker Enterprise to Mirantis · 2019 · stable · top domain 29.7% · bus factor 2 · commercial

    The crisis belonged to Docker Inc's business, not to the code: 134 organisations in the window and clockwork releases. After the sale the core stayed intact (5 of 5) and no fork appeared.

    its caveat D1 of 0.503, exactly on the threshold line: the project survived, but it left half its pace behind.

  • Elasticsearch · licence change to SSPL · 2021 · thrives · top domain 41.1% · bus factor 18 · mixed

    The highest bus factor on the map: 18. The original kept shipping after the licence change and the OpenSearch fork was left at a fifth of its commits in month 24.

    its caveat D1 of 0.801: it clears the continuity bar by hundredths. A handful fewer commits and the label would have been STABLE.

Did the premises hold?

premise 1 · a single company and few hands

partly

OpenOffice meets it textbook-style: 98.8% from one company, the only dot in the red zone, and the fork took the development. But Travis, Redis and Atom degraded outside the corner, for two causes that are the exercise's two findings: since ~2015 teams commit with personal email and the company axis is a floor, not a snapshot (the real sponsor behind Travis or Atom weighed far more than the git shows); and the legal risk of the licence is not in the commits, as Redis teaches.

premise 2 · drama does not soil good code

yes

MySQL, nginx, npm and Docker went through heavily headlined acquisitions and did not degrade: the mechanical label did not get dragged along by the noise. It is the half of the hypothesis that matters most for a due diligence: separating technical truth from the commercial decision is possible and computable.

the method's commitment · frozen rules

yes

Everything was computed with the pre-registration's formulas and thresholds, nothing retouched afterwards. Each case publishes its commands and anyone can reproduce the same number. The premise that took a hit stays as it came out.

OpenOffice: the signal was in the commits

In 2009 OpenOffice looked like the leader of free office software: activity rising, new faces in the core. But 98.8% of the past year's commits came from a single domain. Almost everything was written by people from one company, and that company changed owners. A year later, the LibreOffice fork took the development with it. PostgreSQL, the healthy control at the same cutoff, was the opposite: a federation of independents where no domain owned the project.

one company against a federation 12 month window · as of 2009

OpenOffice · openoffice.org concentrates 98.8%

PostgreSQL · 12 independent domains

Cyan nodes: email domains (the organisations); sized by the % of commits published in the case report (domains with no published %, at minimum size). Grey: OpenOffice's authors, all with an @openoffice.org email. In PostgreSQL, the top domain is Tom Lane's personal machine (42.6%), not a company.

nginx and PostgreSQL: a small team is not an alarm

The people signal, read on its own, would have cried danger twice, both times falsely. nginx reached its eve with bus factor 1 (Maxim Dounin signed 56.8% by himself) and came out of the deal nearly doubling its pace, with the whole core in place. PostgreSQL, with Tom Lane at 42.6% and bus factor 2, is still alive and healthy today. A small team is not a fragile team as long as the company paying keeps paying: no single signal works as a verdict.

And the pattern that matters most for a due diligence: the "commercial with good code" cases do not degrade. MySQL, nginx, npm and Docker went through heavily headlined acquisitions and the mechanical label did not get dragged along by the noise. Separating technical truth from the commercial decision is possible, and it is computable.

Atom: the braking was visible before the announcement

Atom was GitHub's editor, and Microsoft, on buying GitHub in 2018, already had another editor at home (VS Code). What its git says is that the project was already braking before the announcement: the last half-year before the cutoff ran 37% below the one before it. After the deal, the pace settled at 47% of the previous one (from 174.7 to 82.6 commits a month), just under the degradation threshold. The team kept committing (5 of 5), but at retreat volumes: death by business decision, not by the code.

atom/atom · commits per month 2016-2020 · commit date · no merges

Recomputable by anyone on a clone of atom/atom: git log --no-merges --pretty='%cd' --date=format:'%Y-%m' | sort | uniq -c. The dashed line is the cutoff (2018-06-03, eve of the announcement). The prior braking and the later fall are visible to the naked eye; the actual archiving came in 2022, outside the window.

Redis: what the code cannot say

Redis reached its eve healthy on all six signals: many hands, diverse, active, renewing itself. And it degraded anyway: after the licence change, the core left almost entirely and the Valkey fork overtook it within two years. Its risk was legal control of the licence, in the hands of the brand owner with ~21% of the code, and that is not in the git. The code rubric does not see legal governance risk.

Of the five authors who had contributed the most code in the prior year, four left the original repo and reappeared in the fork. They did not leave the project: they left the owner. The fifth, Oran Agra, works at Redis Ltd, the company that owns the brand.

where Redis's core went top 5 pre-event authors · destination post-2024

The width of the flows into Valkey is their number of commits there after the fork (695, 222, 173 and 26, published in the case report). Oran Agra's flow is not to scale: he is the only one of the top 5 still committing in redis/redis and his figure is not published.

The case also leaves a lesson for the method: the same diversity that made the substrate healthy is what made the immediate fork viable. In OpenOffice the monoculture was the risk; in Redis, diversity was the code's life insurance and the owner's problem. The code lives better today than ever, spread across two homes.

Continuity, case by case

Of the sealed rules, the first (D1) measures how much pace each project kept: the commits per month of the two years after the event divided by those of the year before. Below 0.5, the project lost more than half its pace and the rule marks it as strong degradation.

D1: pace kept after the event post 24m / pre 12m · sealed threshold 0.5

Colour follows the final label, which combines D1 with the core exodus and the forks: that is why Redis comes out red with a high D1 (its core left) and npm comes out grey with the group's best D1 (two of its core did not stay). Three cases fall right on the threshold line (0.47 · 0.503 · 0.801) and stay as they are: the threshold was sealed. OpenOffice and PostgreSQL (2009 cutoff) have no published D1 and stay out.

The caveats, one by one

  • n = 11 is illustration, not statistics. The floor of hundreds of repos needed to calibrate weights is still the pending assignment.
  • The email-domain lens under-measures the sponsor since ~2015: teams commit with gmail or a personal domain. In 2009 the corporate email confessed the monoculture; in 2019 it hides it. The horizontal axis of the modern cases is a floor, not a snapshot. The concrete improvement for v1: mailmap and declared affiliations.
  • Legal risk is not in the git. Who can change the licence, who owns the brand, what the contributors signed: none of that shows up in the commits, and Redis proves it.
  • Three labels fall exactly on the threshold line (Atom 0.47; Docker/moby 0.503; Elasticsearch 0.801): they are sensitive to the definition. They are published as they are because the threshold was sealed before computing.
  • Repos imported from another version control system demand manual inspection; two MySQL signals are reported as not cleanly computable instead of a pretty number.
  • The core exodus measures "still committing in the repo", not "still at the company" nor "the project is still alive".

Data and thanks

This exists because these eleven projects develop or developed in the open, with their full history in sight. Thank you.

No affiliation with any of the companies or foundations mentioned. The author names that appear are the public ones from the git itself, and they are cited as what they are: the people huge projects depended on.

Can you use this? Yes. Our computations, the map and the texts on this page are published under a CC BY 4.0 licence: use them, share them or analyse them freely, citing the source, Team Banzai (team-banzai.com). The public repositories analysed keep their original licences.

Built with Python over the git history (git log, committer date), classical statistics and formulas sealed before looking (commit 15bcb3a). The charts are drawn with ECharts. No language model decides anything.

About this demo

A retrospective study, for illustration purposes, over public repositories. It measures signals from the commit history and labels what happened afterwards with formulas fixed in advance; it does not assess the quality of the people cited's work nor pass judgement on the companies. It is not investment advice.

And in your company?

The same cold reading works for measuring your own team's technical debt without depending on what you are told, for auditing a software vendor you rely on before renewing the contract, or for seeing, after a merger, which two systems do the same thing and which one is redundant.

If any of these experiments reminds you of a problem of yours, an acquisition to look inside, a software vendor you cannot tell how much you depend on, data nobody looks at, get in touch and we'll talk it over. No fuss: we'll tell you whether it can be done or not.

← All tech demos