A company can buy a platform. It cannot make everyone who uses that platform trust the new owner simply by completing the paperwork.
That was the problem behind Microsoft's acquisition of GitHub. The headline described a US$7.5 billion transaction. The more interesting story concerned a place where developers worked together, reputations were built in public and decisions about openness carried meaning beyond a conventional software purchase.
Microsoft wanted to reach developers. GitHub already occupied an important place in their working lives. Combining the two created a strategic opportunity and a communication problem: how could a new corporate owner reassure a community without pretending that ownership had not changed?
This is not a story in which every sceptic was proved wrong or every promise was demonstrably fulfilled. It is a story about brand trust under new ownership, the difference between a platform and a community, and the evidence we should demand before calling an acquisition a success.
What Microsoft actually bought
GitHub and Git are not the same thing. Git is a version-control system: a way of recording and managing changes to files. GitHub provides a platform around software development and collaboration. Microsoft's acquisition of GitHub did not turn Git itself into a Microsoft-owned service.
GitHub's introductory documentation explains the platform in terms of storing, sharing and collaborating on code. For a reader outside software, think less of a shelf containing finished products and more of a working environment: people can discuss changes, review contributions and maintain a record of how a project develops.
That is why the brand mattered. A developer's reason for using a platform might involve the tools, the projects already there, colleagues' habits and the ability to demonstrate work. The value is not confined to a piece of software that can be replaced with an equivalent download.
Equally, GitHub should not be treated as a synonym for all open-source software. Projects can use other hosting services or different development arrangements. A platform can be influential without representing every community it serves.
Two dates that should not be confused
On 4 June 2018, Microsoft announced an agreement to acquire GitHub for US$7.5 billion in Microsoft stock. The announcement described a strategy of supporting developers, increasing enterprise use of GitHub and bringing Microsoft's tools and services to new audiences.
The transaction was not completed on that announcement date. Microsoft announced completion on 26 October 2018. Nat Friedman became GitHub's CEO, reporting to Microsoft's Scott Guthrie.
An agreement and a completed sale belong at different points in the timeline. One announces a plan and future commitments; the other records that the sale has happened. Keeping them separate makes the history more accurate.
At completion, Microsoft said GitHub would remain an open platform, operate independently and retain its developer-first ethos. Those were commitments made by the buyer. They are important evidence of the positioning of the deal, but they do not, on their own, establish every subsequent outcome.
The promise was continuity, not invisibility
There are different ways to communicate an acquisition. One is to make the buyer's name dominate. Another is to keep the acquired brand visible while presenting the new owner as a source of support.
Microsoft's GitHub announcement took the second route. The message was not that GitHub would disappear into a generic Microsoft product category. It stressed the preservation of an existing identity and freedom to use different tools and platforms.
In his 26 October 2018 message to the community, Friedman said GitHub would operate independently as a community, platform and business. He also described support for developers' choices of language, licence, tool, platform and cloud, alongside attention to the everyday product experience.
Our interpretation is that these details addressed the practical questions hidden beneath the emotional reaction to a sale. Would users be pushed towards the buyer's preferred tools? Would the platform's character change? Would the things that made the service useful remain a priority?
A vague promise of innovation would not answer those questions. The announcement instead named areas of continuity. That makes it a useful example of communication built around the audience's likely concerns, rather than the owner's excitement about the deal.
Why a retained brand is not a retained relationship
Keeping a name, logo and interface can reduce the immediate sense of disruption. It does not guarantee that the underlying relationship has remained unchanged.
Ownership affects who can make decisions, how priorities are funded and what commercial interests surround a service. Users do not have to reject the acquisition to recognise that those facts matter. Conversely, noticing a conflict of interest does not prove that every product decision will harm them.
This is where a simple good-owner/bad-owner story becomes unhelpful. A platform can receive more resources while also becoming part of a larger commercial strategy. A new feature can be genuinely useful and commercially beneficial to its owner at the same time. Those possibilities are not contradictions.
For branding, recognising a familiar identity is different from trusting what it now stands for. Design can preserve recognition. Trust depends on experience, choices and evidence over time.
A local business changing ownership faces a smaller version of the same issue. Customers may care less about the transaction than about whether the people, quality, opening arrangements and helpfulness they relied on will continue. The announcement should answer those specific uncertainties rather than assuming that the old sign is sufficient reassurance.
Microsoft's change did not begin in June 2018
The GitHub deal is often presented as the moment Microsoft discovered open source. That overlooks earlier documented changes.
On 12 November 2014, Microsoft announced open-source and cross-platform moves for its server-side .NET stack. Its developer team also published a technical explanation of .NET Core becoming open source.
These announcements do not prove that every developer's historical concern had been resolved. They do establish that the 2018 purchase belonged to a longer sequence of changes, not a transformation created by one press release.
That is an important branding lesson. A repositioning becomes more credible when it can point to actions that predate the announcement. Otherwise, the audience is being asked to accept a new description of the business without any supporting behaviour.
We should also avoid reading later events backwards as inevitable. In 2018, users could assess the promises, the existing record and their own alternatives. They could not know every subsequent product decision. The story is more interesting when we preserve that uncertainty.
A promise needs observable evidence
The next question is not whether the acquisition sounded reassuring. It is what changed afterwards, and what those changes can legitimately tell us.
On 7 January 2019, GitHub announced unlimited free private repositories, initially with up to three collaborators per private repository. Public repositories already had a different access model. The distinction matters: the announcement did not say that every feature of every plan had become free.
On 14 April 2020, GitHub announced private repositories with unlimited collaborators for free accounts. The company continued to offer paid plans for additional capabilities and support.
Those are tangible product-access changes. They provide stronger evidence than a general statement that the platform became more welcoming. Yet they still do not establish that the acquisition alone caused every change, that every user approved of it or that the transaction returned its purchase price.
GitHub also expanded workflow automation. Its November 2019 Actions changelog records general availability of GitHub Actions. For non-developers, the relevant idea is that activities around building and testing software could be connected more directly to the place where projects were managed.
The dated announcements let us describe what became available. They should not be turned into an invented numerical claim about how much more productive every team became.
The dissenting view belongs in the story
A flattering acquisition narrative can make scepticism disappear as soon as the buyer ships useful features. That would leave out an important part of GitHub's story.
A 2021 research preprint on Linux and BSD developers' perceptions examined reactions to Microsoft's purchase. Its authors reported 246 survey responses and discussed movement away from GitHub in some communities, together with concerns about the relationship between a commercial hosting platform and free/open-source software.
This is a limited study of particular communities, not a referendum on all GitHub users. It cannot tell us what every developer thought, quantify all migration, or settle the acquisition's overall value. Its usefulness is narrower: it shows why the community should not be described as a single audience with a single response.
Some users may judge a platform primarily by the features available. Others may place greater weight on ownership, governance, independence or the ability to run their own infrastructure. Those priorities can coexist. A branding strategy that assumes only one of them matters is likely to misunderstand part of the audience.
For a business planning a change, the lesson is to distinguish agreement from continued use. People can keep using a service for practical reasons while retaining concerns about it. Silence is not necessarily endorsement, and a busy platform is not evidence that every trust question has been answered.
What counts as success?
Calling an acquisition an effortless harmony makes an attractive headline. It can also smuggle in a conclusion before the evidence has been examined.
Success for whom? Microsoft might evaluate reach, product adoption and financial contribution. GitHub users might evaluate reliability, usefulness, access and freedom of choice. Open-source maintainers might ask whether their projects receive sustainable support. Employees might have a different set of questions again.
These measures overlap, but they are not identical. An acquisition can improve a tool while raising governance concerns. It can increase a platform's scale without making every project more sustainable. It can suit the buyer's strategy without delighting every customer.
The public announcements used here establish dates, commitments and product changes. They do not isolate the transaction's total financial effect or establish that Microsoft's ownership caused every subsequent GitHub development.
Brand stories often become less reliable when they replace a difficult question with an easy label. A useful case study keeps the measures separate.
Three lessons for brands changing hands
Find out what the audience believes it is losing
The owner's idea of the deal may be growth. The customer's concern may be continuity. Before celebrating the new possibilities, explain what happens to the specific things people already rely on.
Make reassurance checkable
A promise such as putting customers first is difficult to assess. A statement about preserving access, supporting choices or maintaining a service is more concrete. It gives the audience something to compare with later behaviour.
Protect the experience, not just the mark
A familiar logo can preserve recognition while the service beneath it changes completely. If trust is the valuable asset, retaining the visible identity is only one part of the work.
These are Time for Designs' practical interpretations, not claims that the same acquisition strategy will work for every business. The scale and economics of a global developer platform are far removed from a local shop. The communication problem, however, is recognisable: people want to know whether the promise they understood still holds.
The part of the purchase that had to be earned
Microsoft acquired GitHub in 2018. It did not acquire the right to be trusted without further evidence.
The deal's communication stressed continuity and developer choice. Later access and workflow announcements supplied observable product changes. Research into particular developer communities showed that the ownership question did not vanish for everyone.
That combination makes the story more useful than either a corporate victory lap or a prediction of inevitable disaster. Brand trust is not transferred as neatly as legal ownership. It has to survive what the new owner does next.
Sources and scope
Dates, transaction terms and product announcements come from Microsoft and GitHub's official records. Community-reaction evidence comes from a clearly identified research preprint with a limited sample. The branding interpretation is our own. Historic plan announcements describe the access offered at the time, not current pricing or product conditions.