Open source product development
We build libraries, tools and applications with documented extension points and contributor-ready structure. Public interfaces are treated as commitments that need deliberate evolution.
Software Engineering
Open source work built for scrutiny and participation
We create and adapt open software with clear interfaces, reproducible releases and governance that considers users and maintainers as part of the system.
Capabilities
What this service delivers
Upstream contributions
Fixes and features are prepared to match a project’s technical and social conventions. Small, evidenced patches improve reviewability and reduce the burden placed on maintainers.
Fork and extension strategy
We assess plugins, upstream changes and maintained forks against control and update costs. Divergence is recorded so security and feature updates do not become guesswork.
Open source adoption
Candidate projects are evaluated for licence fit, maintenance health, security process and operational suitability. Integration plans account for data migration and exit paths.
Release engineering
Automated builds, signed artefact practices, changelogs and compatibility checks make releases repeatable. Dependency and vulnerability handling is assigned an explicit owner.
Technology stack
Tools used for the work
GitGitHub ActionsTypeScriptPythonRustDockerOpenTelemetrySphinx
Process
How the engagement runs
01
Review ecosystem and obligations
We map users, maintainers, dependencies, licences and governance before coding. Existing contribution rules and release cadence shape the approach.
02
Design the public surface
Interfaces, extension points and compatibility policy are proposed with examples. A narrow implementation invites feedback before commitments become costly.
03
Develop in the open
Changes include tests, documentation and rationale suitable for independent review. Security-sensitive findings follow the project’s private disclosure route.
04
Release and maintain
Reproducible automation produces versioned artefacts and upgrade notes. Issue triage, deprecation and dependency updates become an explicit maintenance workflow.
01
Open source adds organisational interfaces
Public code is only one part of an open source project. Contribution guidelines, decision authority, release ownership and response expectations determine whether others can participate safely. We design these mechanisms according to the likely maintainer capacity rather than manufacturing activity.
APIs and file formats need especially careful evolution because adopters update on their own schedules. Semantic versioning helps communicate impact, but tests, deprecation periods and migration notes provide the substance behind a version number.
02
Adoption requires technical and licence due diligence
A popular repository is not automatically a safe dependency. We inspect release recency, issue handling, bus factor signals, transitive dependencies and the project’s security process. Licence compatibility and distribution obligations require informed review, especially when code is modified or embedded.
The architecture should preserve an exit route for consequential dependencies. Adapters, exportable data and documented configuration reduce lock-in to a project that may later change direction. Where a fork is necessary, its patch delta and upstream merge process become maintained assets.
- Licence and notice obligations
- Maintenance and security activity
- Upgrade and migration history
- Cost of replacing or maintaining a fork
03
Contribute in a form maintainers can accept
A large patch that solves one organisation’s exact problem may be difficult for an upstream project to support. We discuss intent early, isolate general capability from local policy and provide focused tests. Existing style and governance deserve respect even when another implementation seems attractive.
Release integrity also matters to adopters. Builds should originate from tagged source through inspectable automation, with dependencies pinned at appropriate levels and changes described clearly. Security reports are handled privately until a coordinated remedy is available.
FAQ
Common questions
Can you customise an existing open source platform?
Yes. We first determine whether configuration, a plugin, an upstream contribution or a fork is the sustainable route, then document the update implications of that choice.
Will our changes be contributed upstream?
That depends on business intent, licence, general usefulness and maintainer acceptance. We can prepare contributions, but no external project is obliged to merge them.
How do you choose an open source licence?
The choice depends on desired reuse, contribution and distribution conditions. We can explain technical implications and implementation obligations, while formal legal interpretation should come from qualified counsel.
Is open source software free to operate?
Usually not. Licence fees may be absent, but evaluation, hosting, integration, upgrades, security response and internal expertise all carry costs.
Can you maintain a private fork?
Yes, with an explicit reason and budget for tracking upstream changes. We minimise divergence, automate compatibility checks and keep a record of patches that must be reapplied or retired.
Related services
Connected engineering capabilities
Plan a open source development engagement.
Share the problem, current system and constraints. We will respond with the questions needed to define a credible next step.