Service 03 · Open Source
A considered approach to open source, before you're already in it.
A two-week advisory to help your team select, license, and integrate open-source components — with a written plan that covers what comes after the initial integration too.
What this delivers
A written integration plan your team can follow and maintain
At the end of this engagement, your team holds a written integration plan that addresses which components to use, why, how they fit into your wider system, and what maintaining and contributing to them looks like over time.
Open source decisions don't end at integration — they continue into maintenance, dependency tracking, and occasionally contribution. This plan prepares your team for that longer arc, not just the initial setup.
2 wks
Engagement duration from first session to written plan
1
Written integration plan covering selection through maintenance
JP
Worked with engineering teams across Japan since 2021
¥34,000
Total investment for the full engagement
Where teams often are
Open source is straightforward to start — and complicated to sustain
Most engineering teams integrate open-source components without a formal process for doing so. A package gets added because it solves a specific problem. Another is pulled in as a dependency of the first. Over time, the system carries components that were chosen under different constraints, under different team members, and under different assumptions about what the system would eventually need to do.
Licensing is a particular area where informal practices can create difficulty later. Different open-source licenses carry different conditions — about distribution, modification, and commercial use — and teams don't always check these carefully when first integrating a component. The gap between what a license permits and what the organisation later needs to do is the kind of thing that's better surfaced early.
For teams approaching open source deliberately — either for the first time or after several years of informal adoption — a structured advisory helps establish a process that holds up over time, not just at the point of initial selection.
Our approach
Two weeks. A plan that accounts for the full lifecycle.
Phase 01
Selection criteria
We work with your team to frame the criteria for selecting open-source components — technical fit, community activity, release cadence, maintenance posture, and alignment with your system's requirements. These criteria become a reusable reference for future decisions.
Phase 02
Licensing considerations
We examine the licenses associated with the components under consideration, describe the conditions each carries, and note where conditions may interact with your intended use. This is an advisory — we aren't legal counsel — but the document gives your team a clear basis for discussion.
Phase 03
Integration plan
We produce a written integration plan that describes how the selected components fit into your wider system, how dependencies should be tracked, and what contribution and maintenance practices are appropriate given your team's capacity and goals.
The integration plan covers
- Selection criteria framed for your team's context and reusable for future decisions
- Licensing notes for the components under consideration
- Integration approach showing how components fit into your existing system
- Maintenance practices — how to track updates, evaluate breaking changes, and stay aware of security disclosures
- Contribution practices — whether and how your team might contribute back, given your capacity
Working together
What the two weeks look like
The engagement is structured around your team's actual situation — the components you're already considering, the system they'd slot into, and the organisational context that shapes what's realistic. We start from what's in front of your team, not from a generic open-source framework.
The advisory sessions are conversational. We work through the selection criteria together, examine the licenses you're dealing with, and discuss what the integration looks like in practice. The written plan reflects those conversations — it doesn't introduce new directions the team hasn't had a chance to consider.
Two weeks is enough time to cover the material carefully without the engagement feeling rushed. We produce a clean, readable document rather than a sprawling reference — something your team can return to in six months and still find useful.
You describe your situation
Which components are you considering? What system are they joining? Is this a first-time open source adoption or a revisit of existing practice?
Advisory sessions over two weeks
We work through criteria, licensing, and integration approach together. The plan takes shape across the sessions rather than appearing fully formed at the end.
Written plan delivered and closed
We hand over the document, walk through it together, answer questions, and the engagement closes. The plan is yours to use, adapt, and reference going forward.
Investment
Transparent pricing, no surprises
Open Source Integration Guidance
Full two-week engagement and written integration plan
¥34,000
What's included
- Advisory sessions across two weeks covering selection, licensing, and integration
- Written integration plan with selection criteria, licensing notes, and maintenance practices
- Contribution practices guidance appropriate to your team's capacity
- Closing walkthrough of the document with time for questions
- Full ownership of all documents — reusable for future open source decisions
Price is in Japanese Yen (¥). We can discuss timing of payment ahead of the engagement start.
Suited for two kinds of teams
Teams approaching open source for the first time, who want to establish a thoughtful foundation from the start. And teams who have been using open-source components informally for several years and want to review and tighten their practices before they create problems.
In practice
What this engagement addresses
Component selection with criteria
Choosing open-source components without explicit criteria tends to produce an inconsistent set — some well-maintained, some not; some with compatible licenses, some ambiguous. Naming the criteria first makes every subsequent decision faster and more defensible.
Licensing made visible
Open-source licenses vary considerably in what they permit and require. The advisory makes the conditions of each relevant license readable and comparable — so your team can make informed decisions rather than assumptions that may need to be revisited later.
Maintenance as a planned activity
Open-source components need ongoing attention — tracking releases, evaluating breaking changes, monitoring security disclosures. The integration plan treats maintenance as something to plan for, not something to address reactively when a problem appears.
The integration plan we produce is specific to your components, your system, and your team's situation. It isn't a generic open-source policy template. Teams who have used it have found it useful both at the time of the engagement and when revisiting their open-source stance later.
Our commitment
What you can rely on from us
The integration plan is written for your situation — not produced from a template and adjusted at the margins. If the components under consideration change during the engagement, we adjust the work accordingly.
On licensing, we're advisory rather than legal counsel. We describe what licenses say and note where their conditions are relevant to your intended use. For decisions with significant legal or commercial implications, we'll say clearly when the right next step is speaking with a lawyer rather than relying on our notes.
If the document we produce doesn't address what your team described as its situation at the start of the engagement, we'll revisit it. The engagement closes when the plan is genuinely useful, not when a fixed number of sessions has elapsed.
A note on scope
This is an advisory and planning service — not implementation support. We help you decide what to integrate and how to approach it. The actual integration is your team's work to carry out, guided by the plan we produce together.
Getting started
From first message to integration plan in two weeks
01
Write to us
Describe what you're considering integrating and what's prompted the question now. A few sentences is enough to start.
02
We confirm the fit
We read your message, confirm whether the engagement suits your situation, and agree on a start date for the two-week advisory.
03
Advisory sessions run
Sessions are scheduled across two weeks. The plan develops through the conversations, shaped by your team's feedback and constraints.
04
Plan delivered
The integration plan is yours. We walk through it, take your questions, and close the engagement. You're ready to proceed with the integration.
Open Source Integration Guidance · ¥34,000
Ready to approach open source with a considered plan in place?
Send a short message describing what you're working with and what you're trying to figure out. We'll respond within one business day and let you know whether this engagement fits.
Get in touchOther services
Explore other ways we can help
Service 01
DevOps Workflow Review
Three sessions examining your build practices, deployment cadence, and operational handoffs. Written observation report with ordered recommendations. ¥22,500
Service 02
Cloud Architecture Consultation
Four sessions covering requirements, architectural sketching, and a reference document for teams preparing a measured cloud rollout. ¥43,000