TL;DR
• Open source is the only linkable asset you permanently lose control of the moment you publish it. That is not a risk to manage — it is the mechanism.
• You cannot require the link. Open-source licensing norms bar it, and Google’s spam policy bars it independently. Two locks, one lever, and the licences that tried to force it were exiled to the margins of the ecosystem twenty years ago.
• Almost every link the ecosystem produces is nofollow by default. The followed ones come from developers writing about problems your library gave them — a channel you cannot commission.
• The cost-per-link inversion: for every other linkable asset, cost per earned link falls over time. For open source it rises, permanently, because the link curve decays while the maintenance curve does not.
• From 11 September 2026, an organisation publishing software commercially into the EU may carry “open-source software steward” obligations under the Cyber Resilience Act, including 24-hour and 72-hour vulnerability reporting.
• You cannot cleanly stop. An abandoned repository with open security advisories is a brand liability, and it ranks for your own name.
• The conclusion: never ship open source to get links. Ship it for a product, hiring or credibility reason, and take the links as a by-product — that is the only cost structure where the arithmetic works.
What open source actually does to your link profile
The standard advice is descriptive and technically true: publish a package and you generate links from every project that references it — documentation sites, README files, package aggregators, dependency dashboards, all pointing back. What the description misses is that the links divide into two populations with almost nothing in common, and only one of them is a link asset.
Here is the honest inventory.
| Source | Follow status | Who controls it | Can you commission it? |
| Repository host (GitHub, GitLab) | Nofollow | The platform | No — the attribute is fixed |
| Package registries (npm, PyPI, RubyGems, Maven) | Nofollow | The registry | No |
| Q&A platforms (Stack Overflow) | Nofollow / ugc | The platform | No, and attempting to is spam |
| Curated “awesome” lists | Usually nofollow, repo-hosted | List maintainer | You can submit; they decide |
| Third-party documentation and tutorials | Often followed | Independent authors | No — they write when they hit a problem |
| Engineering blogs and newsletters | Followed | Independent editors | Only indirectly, through the work itself |
| Dependency listings on users’ own sites | Mixed, usually template-level | Your users | No |
Read down the last two columns and the shape of the problem appears. Every source you can influence produces a nofollow link. Every source that produces a followed link is written by somebody with no relationship to you, no obligation to you, and no reason to tell you it happened.
That inverts the normal control structure of link acquisition entirely. In outreach you choose the target and negotiate the placement. Here you cannot even identify the population in advance — you find out you were linked when your referral logs move. It also makes the usual planning artefacts useless: there is no prospect list, no pitch, no follow-up sequence. Anyone selling you an open-source link building strategy with a pipeline attached is describing something that does not exist.
The one lever you cannot pull, locked twice
When a distribution channel produces mostly nofollow links, the reflex is to require a better one. It is what badge programmes do, what widget vendors try, and what attribution licensing was invented for. In open source that reflex is blocked by two independent mechanisms, and it is worth seeing that both locks exist — because teams who route around one always walk into the other.
The licensing lock. No OSI-approved licence requires a hyperlink. MIT and the BSD family require that the copyright notice and permission text survive in redistributed copies. Apache-2.0 requires that a NOTICE file, if present, be carried forward. The GPL requires appropriate legal notices on interactive startup. Every one of those is a requirement about text — a name, a notice, a licence body. None of them is a requirement about an anchor pointing at a domain you own.
The search-policy lock. Suppose you write your own licence that does require a link. You have now drafted precisely the arrangement Google’s spam policy names: requiring a link as part of a contract or similar arrangement without allowing the content owner the choice of qualifying the outbound link. The clause was written for terms-of-service link requirements, and a bespoke software licence is the same instrument wearing different clothes.
And the artefact can walk away from you
There is a third loss of control that has no equivalent anywhere else in link building: anybody may take the code, rename it, and continue without you. A permissive licence makes this explicit, and a copyleft one only constrains how the derivative is licensed, not whether it exists.
The last few years supplied unusually clear demonstrations. When Elastic moved Elasticsearch off its open-source licence, the ecosystem produced OpenSearch. When HashiCorp relicensed Terraform, the response was OpenTofu under the Linux Foundation. When Redis changed terms, Valkey appeared and absorbed much of the community. In each case the original vendor kept the trademark and lost a meaningful share of the mindshare, the documentation gravity and the citations that had accumulated around the name.
The link-strategy reading is uncomfortable but simple. The asset you are investing in is a reputation attached to a name, and the name can be forked away from the code that earned it. That is a risk profile no owned content asset carries, and it belongs in the decision before you publish rather than in a retrospective afterwards.
The double bind, stated once
A licence that requires a link is not open source, because the community rejected that class of licence twenty years ago and the ecosystem never took it back.
And a licence that requires a link is a named Google violation, because a licence is a contract and the clause covers contracts.
The two locks are independent. Satisfying one does not release the other, and there is no drafting that escapes both.
The Attribution Ceiling
This is not hypothetical history. Between 2006 and 2007 a group of commercial open-source vendors — SugarCRM, Centric CRM, Socialtext and others — shipped modified versions of the Mozilla Public License that required downstream users to display a logo and a link back to the vendor’s website on every screen. The category acquired a name: badgeware.
The Open Source Initiative fought about it for roughly nine months. Opponents, including OSI figures such as Michael Tiemann, argued that such requirements were incompatible with the spirit of open source and that the obligations compounded absurdly — combine code from several badgeware projects and a downstream product ends up carrying a wall of mandatory logos, with the duty surviving even when almost none of the original code remains. On 30 July 2007, OSI approved Socialtext’s Common Public Attribution License, which permits a required attribution notice, and the approval was immediately controversial.
The instructive part is what happened next: essentially nothing. CPAL exists, is OSI-approved and FSF-approved, and is used by almost nobody. The market settled on permissive licences with text-only notice requirements, and the attribution-licence experiment became a footnote. That outcome is the ceiling, and it has held for nearly two decades.
| Licence family | What it lets you require | Link requirement? |
| MIT / BSD | Copyright notice and permission text preserved in copies | None |
| Apache-2.0 | NOTICE file contents carried into derivative works | None — text only |
| GPL family | Appropriate legal notices on interactive startup | None |
| MPL 2.0 | File-level source disclosure; notice preservation | None |
| CPAL-1.0 (badgeware) | A visible attribution notice, potentially graphical | Permitted in principle; effectively unused |
| CC-BY (for docs and datasets, not code) | Attribution to the creator, with a URI if one was supplied | The closest thing that exists — and it is not software |
The one genuine opening in that table is the last row, and it is worth taking seriously: documentation, datasets and benchmark results are not code and can be released under Creative Commons terms that ask for attribution with a link. If you have a data asset attached to your project, that is where an attribution request is both customary and enforceable. It is a small opening, and it is the only one.
Note the asymmetry it creates. The software — the expensive, permanent, regulated part — gives you no attribution rights worth naming. The dataset or the benchmark alongside it — cheap to produce, easy to retire, carrying no maintenance obligation at all — gives you the strongest attribution position available. If a link is genuinely what you are optimising for, you are looking at the wrong half of the project, and the cheaper half is the one that works.
Why your links track your library’s rough edges
Now the mechanism that determines who actually links to you, which is stranger than the literature admits.
Followed links to an open-source project come overwhelmingly from people documenting a problem. A Stack Overflow answer explaining a confusing default. A blog post titled after the error message somebody spent an afternoon on. A migration write-up. A comparison written by a team that evaluated three options and had opinions. Almost none of it is written because your library is elegant. It is written because somebody hit friction and wanted to save the next person the same afternoon.
Which produces an uncomfortable correlation: link volume tracks how widely encountered and how initially confusing your project is, not how good it is. A library with immaculate documentation, obvious defaults and no famous gotchas generates markedly less third-party writing than one with a well-known trap in it.
The conclusion you must not draw
Do not degrade your documentation to farm problem-solving content. It is a real mechanism and a terrible instruction.
Friction reduces adoption, and adoption is the thing the entire strategy runs on. Trading adoption for blog posts trades the asset for the shadow it casts.
The correct response is the opposite one: write the definitive troubleshooting content yourself, on your own domain, and let the third-party posts link to it as the canonical answer. You convert a link you cannot commission into a destination you own.
That last move is the single highest-leverage thing an SEO team can do with an open-source project, and it is nearly always left undone. Engineering owns the repository, the docs live on a subdomain or a docs platform, and the troubleshooting content that the whole ecosystem cites gets written by strangers. Claiming it is a content decision, not a link-building one, and it is closer to winning the definitive answer for a query than to outreach.
The real asset is your name in other people’s build files
Step back from links entirely for a moment, because the most valuable thing open source produces is not a hyperlink and never has been.
A widely adopted package puts your project name into a build manifest — a package.json, a requirements.txt, a go.mod, a Gemfile — in every repository that depends on it, directly or transitively. Those files are committed, versioned, mirrored, vendored and copied. They are not links. They are a distributed namespace claim, and they persist in places no link would reach.
// The asset, as it actually appears in the wild
“dependencies”: {
“your-library”: “^3.2.0”,
“some-other-thing”: “^1.0.4”
}
// No anchor. No rel attribute. No referring domain.
// Present in every dependent repository, permanently.
In 2026 this matters more than it did, for a reason that has nothing to do with PageRank. Build manifests, READMEs and issue threads are heavily represented in the corpora behind code assistants and general-purpose models. When a developer asks an assistant which library to use for a task, the answer is shaped by how often your name appears alongside that task across public code and public discussion — not by how many followed links point at your marketing site.
So the measurement frame has to change with it. Referring domains are the wrong headline number for an open-source project. Adoption, co-occurrence of your project name with its problem category, and appearance in assistant recommendations are the things that move. Treat the benchmarks for link acquisition by tactic as context for the editorial layer only, and judge the project itself on adoption.
The cost-per-link inversion
Here is the structural finding, and it is the reason open source fails as a primary link strategy even when it succeeds as software.
For every other linkable asset, cost per earned link falls over time. You build a calculator or a dataset once, and it keeps accumulating links against a fixed build cost, so the average cost per link declines month after month. That declining curve is the whole economic case for linkable assets.
Open source inverts it. Editorial attention is front-loaded — launch coverage, awesome-list additions, the first wave of tutorials — and then decays. Maintenance is back-loaded and permanent, and it grows with adoption: more users generate more issues, more edge cases, more security reports, more compatibility work. The link curve falls while the cost curve rises, so cost per link climbs monotonically and never turns around.
Put plausible numbers on it. Tidelift’s maintainer research puts the average unpaid maintainer at roughly 8.8 hours a week, with popular projects demanding 20–30. Take a moderately successful library maintained inside a company at a quarter of an engineer rising to two-fifths as adoption grows, and cost it at a conservative all-in UK engineering rate.
| Year | Maintenance load | Annual cost | New editorial referring domains | Cumulative cost per domain |
| 1 | 0.25 FTE | £18,750 | 35 | £536 |
| 2 | 0.35 FTE | £26,250 | 12 | £957 |
| 3 | 0.40 FTE | £30,000 | 8 | £1,364 |
| 4 | 0.40 FTE | £30,000 | 6 | £1,721 |
| 5 | 0.40 FTE | £30,000 | 5 | £2,045 |
The figures are illustrative; the shape is not. Whatever your inputs, the final column only ever goes up, because the numerator compounds and the denominator decays. There is no year in which an open-source project becomes a cheaper source of links than it was the year before. Run the same calculation for your other channels using the tools that report referring domains earned per campaign, and the comparison usually settles the argument in one meeting.
What this does and does not prove
It does not prove open source is a bad investment. It proves open source is a bad investment when links are the reason for it.
If the project also serves a product need, a hiring channel, a partner integration or a credibility argument in enterprise sales, the maintenance cost is already justified and the links arrive free. The arithmetic only fails when the links have to carry the whole cost.
Which gives you the decision rule: if you cannot name a non-SEO reason that alone would justify the maintenance budget, do not ship it.
Cost at volume, failure modes, and the threshold
- Real cost drivers. Beyond maintainer hours: security review and dependency patching, release engineering, a documentation site with its own hosting and build pipeline, and the review time senior engineers spend on external pull requests. Budget the last one honestly — community contributions are a cost centre before they are a benefit.
- Failure mode one: the ghost repository. Adoption never arrives, the project sits at a handful of stars, and it becomes evidence of an abandoned initiative sitting on your organisation’s public profile. Low adoption is not a neutral outcome.
- Failure mode two: the success trap. Adoption exceeds what you staffed for. Issues outrun response time, the project acquires a reputation for being unmaintained while still being widely used, and the reputational effect runs opposite to the one you wanted.
- Failure mode three: licence drift. A dependency changes to a restrictive or source-available licence and your permissive project inherits a conflict. Run licence scanning in CI from day one, not after somebody in procurement asks.
- Reproducibility. Keep a dated record of releases, licence at each release, the NOTICE contents, and your dependency manifest. When a downstream user or a regulator asks what you shipped and under what terms in a given month, that record is the answer.
- Failure threshold. If after twelve months the project has produced neither meaningful adoption nor the non-SEO benefit you justified it with, stop — but stop properly, using the deprecation sequence below. Do not respond by writing a link requirement into the licence, which fails both locks at once.
- Cheaper fallback. A hosted tool or a public dataset on your own domain earns editorial links against a fixed build cost, on a declining cost-per-link curve, with no permanent maintenance obligation and no regulatory exposure. It is the same audience and roughly a tenth of the commitment.
The abandonment trap
Every other link tactic can be stopped. You can end an outreach programme, retire a widget, withdraw a badge. An open-source project you cannot cleanly stop, and this is the asymmetry that makes shipping it a different class of decision.
Once a package is published and depended upon, three things become true simultaneously. The code is out under a licence you cannot revoke. Downstream users have a reasonable expectation of security maintenance. And the repository ranks for your own project and company names, so whatever state you leave it in is what people find.
The industry has a live example. Kubernetes Ingress NGINX — infrastructure used at enormous scale — was confirmed to receive no security patches after March 2026, with maintainer capacity the stated cause. That is not an obscure hobby project; it is a component sitting under production systems worldwide. The failure mode is real and it reaches the top of the ecosystem.
The supporting data is not encouraging either. Tidelift’s maintainer research found 60% of maintainers unpaid, 60% having quit or considered quitting, and 44% citing burnout as the reason, with 61% of unpaid maintainers working alone. Paid maintainers were substantially more likely to implement critical security practices. If your open-source project is a marketing line item, it is structurally in the unpaid, understaffed category regardless of who signs the payslip.
The regulatory layer most SEO coverage misses entirely
There is now a compliance dimension, and the timing is immediate. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, created a category called the open-source software steward — an entity that supports the development of in-scope open-source software in a business context, including not-for-profits. Stewards carry lighter duties than manufacturers: no CE marking, no conformity assessment. They are not, however, nothing.
Under Article 24, a steward must maintain a documented cybersecurity policy, cooperate with market surveillance authorities, encourage voluntary vulnerability reporting, and remediate vulnerabilities without undue delay. From 11 September 2026 the reporting obligations bite, with an early warning inside 24 hours and fuller notification inside 72 for actively exploited vulnerabilities. Remaining obligations follow on 11 December 2027, and the European Commission issued draft guidance in March 2026 that is still settling.
Why this lands on a UK company
The regulation follows the market, not the office. A UK organisation publishing software that is used commercially in the EU can be in scope, and the linked article on European link building covers the wider pattern of EU rules reaching UK publishers.
A marketing-motivated repository is exactly the kind of project where nobody has considered this, because it was scoped as a content initiative rather than as software the company distributes.
None of this is a reason to avoid open source. It is a reason not to ship it for link-building reasons, because a link-building budget will not fund a 24-hour vulnerability reporting capability.
For the broader pattern of European regulation shaping UK search and publishing decisions, see our coverage of link building for European markets.
Deprecating properly
If you do stop, the sequence matters, because a badly abandoned repository actively works against the brand it was meant to help.
- Announce the end of maintenance with a date, in the README and in a release, before the date arrives.
- Resolve or explicitly close outstanding security advisories. Open advisories on an archived repository are the worst possible artefact to leave behind.
- Name a successor project or a fork if one exists, or state plainly that none does.
- Archive rather than delete. Deleting breaks every build that depends on you and generates precisely the write-ups you do not want.
- Keep the documentation live and redirect it nowhere clever. A working docs page for a retired project is a courtesy; a redirect to a sales page is the move people write blog posts about.
What actually earns the followed links
Given that the repository itself produces nofollow links and the followed ones cannot be commissioned, the practical question is what you can legitimately do to increase the odds. There are four things, and none is outreach.
Publish the reasoning, not the announcement. Nobody links to a release note. The pieces that get cited are the ones explaining why the existing options were inadequate, what design decision you took, and what it cost — with the failure states included. An honest engineering post about an approach that did not work earns more editorial attention than any launch.
Own the benchmark. If your project occupies a category with competing options, publishing a rigorous, reproducible, self-critical comparison — including where you lose — makes you the citable source for the whole category. Publish the methodology and the raw results under a Creative Commons licence, which is the one place an attribution request with a link is both customary and defensible.
Write the canonical troubleshooting page. As above: the third-party posts documenting your library’s friction are being written whether you participate or not. Being the definitive answer they link to converts the mechanism in your favour.
Show up where developers already are. Conference talks, technical newsletters and community write-ups produce followed editorial links from domains you could never buy access to. This is closer to sponsorship and community-based acquisition than to outreach, and it is judged by the same standard: is the contribution real?
Answer well, in public, where it is indexed. Issue threads, discussion boards and Q&A answers are read far more often than they are written, and a thorough maintainer reply becomes the thing other people cite for years. The links from those pages are nofollow, but the citation behaviour they trigger is not: a well-explained answer gets referenced in write-ups, documentation and training corpora long after the thread closes.
The anti-pattern
Submitting your project to every “awesome” list, directory and aggregator you can find is the open-source equivalent of directory submission, and it works about as well.
The links are nofollow, the lists are repo-hosted, and maintainers of the good lists reject transparent self-promotion. One submission to the genuinely relevant list is worth more than forty scattered ones.
Volume of placement is not the variable here, and it never was.
What to measure, and what to stop reporting
Report adoption first: downloads or installs, dependent repositories, and the share of those that are commercial rather than experimental. Report editorial referring domains second, and only those from independent authors — registry and repository links should be excluded from the count entirely rather than reported as nofollow, because including them creates a number that rises with nothing and misleads everyone who reads it.
Then report the two things that actually justify continuation: the non-SEO benefit you named at the outset, measured directly, and the running cost per editorial referring domain. If the second is climbing and the first is not materialising, you have your answer without needing a debate about it.
When not to ship open source
The honest exclusions, which are broader than the enthusiasm suggests.
- You have no engineering capacity to commit permanently. Not for the launch — for years. If the maintenance owner is a marketing budget line, the project will fail publicly and slowly.
- Your audience is not technical. If the people who make buying decisions in your market never read a repository, the entire mechanism — adoption, dependency listings, developer writing — is missing. Nothing about open source helps a business whose buyers are not engineers.
- The project would expose sensitive logic. Publishing the thing your commercial advantage rests on to earn links is a bad trade at any link volume.
- You want attribution more than adoption. If the appeal is having your name on other people’s screens, you want a badge programme or a product attribution model, not a licence — and those have their own constraints. Wanting the credit more than the usage is a reliable signal that the project should not be open source.
In each case the alternative is the same and is genuinely better: build the equivalent asset on your own domain, where you keep the traffic, control the destination, and can retire it when it stops paying. Our guide to how link value is actually assessed sets out why owned assets usually win that comparison.
Worked example: a UK logistics platform
Anonymised and lightly rounded; the sequence is real.
A Manchester logistics-software company built an internal library for parsing and validating UK carrier tracking formats — an unglamorous problem their engineers had solved properly and everybody else in the sector solved badly. Marketing proposed open-sourcing it as a link-building initiative, projecting links from GitHub, npm, awesome-lists and developer blogs.
What the pre-ship analysis found
Running the inventory first changed the framing before a line was published. The projected GitHub, npm and Stack Overflow links were all nofollow. The realistic editorial estimate for a niche B2B utility library was 20–30 referring domains in year one, not the low hundreds in the proposal.
Costed at a quarter of an engineer, year one came to roughly £19,000 against perhaps 25 editorial referring domains — about £760 each, with the figure guaranteed to rise every subsequent year. Their existing content programme was acquiring editorial links at materially less than that.
The CRA question had not been raised at all. The library would be published in a business context and used commercially by EU logistics firms, putting steward obligations plausibly in scope before the September 2026 reporting date. Nobody in the proposal owned a 24-hour vulnerability response.
What they did instead
They shipped it anyway — for a different reason, with a different owner and different success criteria. Engineering wanted it because customer integrations kept failing on carrier format edge cases, and a public library that integration partners could adopt directly reduced support load. That justified the maintenance budget on its own, which is the test set out above.
A review of where competitors in the category were actually earning links reinforced the point from the other direction: three rivals had published repositories, and none of them had earned a meaningful editorial link from any of them. The category’s links were coming from data, comparisons and trade press — not from code.
The link programme was rebuilt around the parts they controlled. They published the carrier-format specification research as a documented dataset under a Creative Commons licence with an attribution request. They wrote the canonical troubleshooting guide for the format quirks on their own domain rather than in the repository. They put the engineering reasoning — including two approaches that failed — into a long technical post.
Outcome
The repository produced roughly what was predicted: mostly nofollow links, modest adoption, and no measurable ranking effect.
The dataset and the troubleshooting guide, both hosted on the company domain, earned the majority of the editorial referring domains attributable to the whole initiative — and they cost a fraction of the library.
Support tickets on integration format errors fell, which is what actually paid for the project.
The lesson is not that open source failed. It is that the links came from the assets they owned, and the software justified itself on grounds that had nothing to do with search.
The decision, in order
If somebody proposes open source as a link strategy, work through these in sequence. Most proposals stop at the second step.
- Name the non-SEO justification. Product need, hiring, partner integration, enterprise credibility. If no single one of those would justify the maintenance budget alone, stop here.
- Cost the tail, not the launch. Model five years of maintenance at a realistic FTE fraction and compute cost per editorial referring domain each year. Compare the final column against your current cost per link from other channels.
- Check the regulatory position. Establish whether the organisation would be an open-source software steward under the CRA and who owns vulnerability reporting. Do this before publishing, not after a disclosure arrives.
- Choose a standard permissive licence. MIT or Apache-2.0. Do not draft attribution terms; the ceiling described above is real and the workarounds fail two independent tests.
- Decide where the documentation lives — and choose your own domain. This is the single decision with the largest link consequence, and it is usually made by default in the wrong direction.
- Publish the surrounding assets deliberately. Benchmark, dataset under Creative Commons, engineering reasoning, canonical troubleshooting. These are the parts that earn followed links and the parts you control.
- Set the deprecation policy on day one. Write down what happens if the project is not maintained in three years. A project with no exit plan does not get an entry.
Followed through in that order, open source stops being a link tactic and becomes what it always was: a serious engineering commitment that produces reputational and discovery benefits as a by-product. That is a considerably better description than the one in circulation, and it has the advantage of surviving contact with the maintenance budget in year three.
