January 23, 2026
Most of Umbricians’ work supports US companies, but some of the clearest, most actionable “build it right” guidance on open source comes from the UK government. The UK is unusually direct about expectations, which makes it a useful benchmark for any serious delivery team, even if you are not building for the public sector.
In the UK, the Digital, Data and Technology Playbook states there is an expectation that government software and code is open-source by default, developed in the open, and published using an Open Source Initiative (OSI) approved licence. (Digital, Data and Technology Playbook)
In the US, the federal government has also pushed “default to open” thinking through policy like the Federal Source Code Policy (and its originating OMB memo). While those rules apply to federal agencies, the underlying principles are a strong model for modern delivery and procurement anywhere. (Federal Source Code Policy overview, OMB M-16-21)
So the practical question for US teams is not “Do we have to do this?” It is “How do we do this safely and in a way that improves maintainability, reduces vendor lock-in, and makes handoffs cleaner?”
Why keep the UK framing if you mainly serve the US?
Because the UK guidance is explicit enough to turn “be open” into concrete delivery requirements. For example, the UK Service Standard says: make new source code open and reusable, publish it under appropriate licences, or provide a convincing explanation for exceptions. (Service Standard point 12)
And the UK’s Technology Code of Practice requires plans to show you have considered using open source and publishing code openly. (Be open and use open source, Technology Code of Practice)
Even if you are a US company, adopting these same patterns is a fast way to raise delivery maturity and credibility with security teams, regulated industries, and enterprise buyers.
What “open-source by default” means in practice
Upgrading on time is more than a maintenance best practice. There are real risks associated with staying on an unsupported version. If you need short term help stabilizing an older site, our team provides focused end of life support while you plan the move.
This is the part delivery teams actually need.
1) Decide what will be open from day one
Teams get stuck when “open source” becomes a final sprint chore. The better approach is to define your open surface area early:
-
What repos will be public
-
What must stay private (and why)
-
When you will publish (alpha, beta, launch)
In UK government, the expectation is that you work in the open as part of delivery. Some departments even document “work in the open” as an explicit practice aligned to these standards. (Work in the open, Home Office)
2) Put code in a public repo, including supplier-built code
UK guidance is direct: you should make your code publicly available in an open internet repo, and that includes code developed by third parties (like agencies). (Making source code open and reusable)
That matters for US companies too, especially if you want clean handoffs or multi-vendor flexibility. If you have inherited a brittle Umbraco build, it can make sense to stabilize first, then open it up. That is where Umbraco Help & Rescue fits naturally into an “open by default” roadmap.
3) Choose an OSI-approved licence early (not at the end)
The UK Playbook explicitly calls out OSI-approved licensing. (Digital, Data and Technology Playbook)
The OSI’s list of approved licences is the reference point. (OSI Approved Licenses)
Practical team rule: decide the licence before you publish the repo, add it on day one, and document contribution expectations clearly.
4) Document it so another team can actually run it
The Playbook ties open and interoperable software to clearer documentation and easier maintenance and reuse. (Digital, Data and Technology Playbook)
A simple baseline that works for US delivery teams:
-
README with local run instructions and deployment overview
-
Architecture notes (short, readable)
-
Environment templates (no secrets)
-
Release notes
When your CMS connects to CRM, ERP, identity, or analytics tools, that documentation becomes even more important. FYIN’s broader integration capability is a useful “big picture” reference when Umbraco is only one part of the system.
“Safe open” is not optional
Publishing code does not mean publishing everything. Government engineering guidance gives concrete examples of what should not be public, like keys and credentials, certain fraud detection logic, and details of unannounced policy. (GDS Way: source code)
Safe patterns that apply cleanly to US companies:
-
Keep secrets out of source control (vaults, environment variables, managed secrets)
-
Split public app code from sensitive infrastructure topology where needed
-
Automate secret scanning and dependency checks in CI
If you want this to be sustainable long-term, support and patching cannot be an afterthought. This is where Umbraco Support & Maintenance and Umbraco Long-Term Support align with “open by default” goals because they keep your platform healthy after publishing.
Avoiding “new legacy” (a universal problem, not a UK-only one)
Open code that runs on end-of-life frameworks becomes a liability for the next team. The best “open by default” implementations treat upgrades as routine.
If you are on older Umbraco versions, an upgrade plan is part of delivery quality, not just a technical chore. Umbraco Upgrade Services and End-of-Life Support are the pragmatic bridge from “legacy reality” to “open and maintainable.”
If you want a complementary perspective on evaluating partners beyond badges, FYIN’s post Choosing the Right Umbraco Partner fits nicely in a paragraph about supplier selection and handover.
A practical checklist you can adopt in US delivery
If you want an “open-source by default” approach that works for US companies and still borrows credibility from UK government standards:
-
We define what will be open, what will be private, and when we publish. (DDaT Playbook)
-
We publish code in a public repo, including supplier-built code where appropriate. (GOV.UK guidance)
-
We choose an OSI-approved licence and document contribution. (OSI licenses)
-
We document so another team can run and maintain the service. (DDaT Playbook)
-
We apply safe-open patterns (no secrets, no sensitive operational details). (GDS Way)
-
We have an upgrade and support cadence so published code stays supportable. (Umbraco Support)
Closing
UK government guidance is not only “UK policy.” It is a clear, high-bar operational blueprint for doing open source responsibly. Combine that with the US federal push toward reusable and open code, and you have a strong playbook for building software that is easier to maintain, safer to operate, and less dependent on any single vendor. (Federal Source Code Policy, DDaT Playbook)
If you want help turning these standards into a real repo structure, documentation set, and upgrade plan for an Umbraco platform, start with a short discovery conversation with Umbricians.
Stop shipping new legacy
Talk to Umbricians about an upgrade and support plan that keeps your Umbraco platform in mainstream support.
