Part 07
Balancing Openness Cultural Safety
Speaker 1: When we say "open" in tech circles, people assume GitHub repos and
creative commons everything. But for Indigenous communities, openness is negotiated,
relational and grounded in tikanga. Our goal here is to show how you can invite
collaboration without handing over guardianship of taonga.
Speaker 2: Right, and it’s not just an ethical stance—it’s a strategic one. Communities
want to drive impact from language archives, climate data or health studies, yet
they’ve seen extractive research hollow trust. Balancing openness with cultural safety
means designing processes that answer "who benefits?" and "who decides?" before a
single CSV is shared.
Speaker 1: Frameworks like CARE and OCAP® give teams language to operationalise
sovereignty. They flip the script from FAIR’s "make everything findable" to "how does
this data deliver collective benefit, and who retains authority to say no?"
Speaker 2: Exactly. When you cite UNDRIP Articles 18 and 31 in an agreement, you’re
grounding decisions in international law that recognises cultural expressions as living
knowledge. That empowers community tech-leads to slow down eager researchers and
convene hui before any export happens.
Speaker 1: Consent isn’t a one-off signature; it’s an ongoing conversation. We’re
recommending teams define sensitivity tiers so elders can differentiate between
language-learning clips that can go to schools versus karakia that never leave the
marae.
Speaker 2: And document the stories behind the data. Provenance notes, cultural
narratives and explicit usage boundaries travel with the dataset so future analysts
understand the tikanga context. That’s how you avoid someone training a model on
sacred audio because they only saw a file name.
Speaker 1: Tiered portals and review boards are how you translate those principles into
day-to-day decisions. Whānau get first access, then trusted researchers who have gone
through cultural briefings and signed reciprocal data-sharing agreements.
Speaker 2: Governance lives in the paperwork too—MOUs that spell out kaitiaki roles,
dispute resolution and benefit-sharing. Add Traditional Knowledge labels so licences
travel with files, and insist partner institutions appoint liaison staff accountable back to
the tribal council.
Speaker 1: People sometimes assume cultural safety is just policy, but the tech stack
matters. Attribute-based access control lets you honour roles and protocols, and audit
logs show exactly who downloaded which clip and when.
Speaker 2: Pair that with encryption keys controlled by community stewards and
monitoring for unusual usage. If someone suddenly scrapes thousands of files, alerts
fire and the licence can be paused while you convene a restorative hui. Technology
becomes a guardian alongside people.
Speaker 1: The roles slide shows this isn’t a solo act. You need cultural advisors sitting
with engineers, and data stewards who can translate tikanga into access policies.
Typically it’s one cultural lead per squad and a steward overseeing three to five
partnerships.
Speaker 2: Career-wise, we’re seeing interns from iwi digital hubs grow into community
tech-leads, while policy analysts pivot into Chief Data Steward roles. The common traits
are relational intelligence, patience and the ability to negotiate between community
expectations and platform roadmaps.
Speaker 1: The scenario is intentionally practical. A university wants to add iwi audio to
an open corpus, but they first have to produce a CARE-aligned impact statement and
show how whānau benefit. Access is time-bound and requires reporting back in te reo
Māori.
Speaker 2: And there’s accountability—breaches trigger suspension, a restorative hui
and potentially pulling derivative models. That’s the message: openness isn’t the
absence of control, it’s shared responsibility with cultural governance setting the
guardrails.
Community Governance Structures
Speaker 1: Now that we’ve wrapped the Te Hiku kōrero, let’s switch lenses to the
mainstream open-source world. Governance in open source isn’t just paperwork; it’s
how communities decide who shows up, who has a vote and how funding gets spent.
Most projects start with one person saying “I’ll just share this script,” then suddenly
hundreds of organisations rely on it. The structures we put around that growth
determine whether the maintainer burns out or builds a sustainable ecosystem.
Speaker 2: Treat this as a fresh thread, not a continuation of the Indigenous practice
section. Think about governance as progressive scaffolding. You don’t pour concrete
foundations for a garden shed, but you also don’t balance a skyscraper on a folding
chair. For the coworking-sized projects in the middle, you need modular
beams—enough structure to host dozens of teams without locking down every desk. As
usage and contributions scale, the project needs sturdier guardrails, documented
decision-making and support for the humans keeping the lights on.
Speaker 1: In the solo maintainer phase, governance is basically the maintainer’s
judgment plus whatever norms they capture in the README. That works because
decisions are fast, but it concentrates risk. If they get sick or start a new job, issues and
security patches stall. I like asking solo maintainers to publish a roadmap and
contributor expectations so the community knows how to help.
Speaker 2: Another practical step is to recruit lieutenants. Give a few trusted
contributors triage or release permissions, even on a trial basis. Speaking of
lieutenants, how do you actually identify who to trust? Start with the folks who reliably
follow contribution guidelines, communicate edge cases and respect boundaries. It
lowers the bus factor and gives the maintainer a support network before stress turns
into burnout. And by “stress” we mean the 3am “the server is down and only I know the
deployment password” kind of stress.
Speaker 1: Once you have three to ten maintainers, things shift to a core team model.
That’s where you add deliberate roles—reviewers, release leads, community
moderators—and rotate them so nobody becomes the bottleneck. It also helps to
document how decisions get recorded. Lazy consensus, for example, means proposals
pass unless someone objects within a set timeframe.
Speaker 2: The key is transparency. Publish decision logs in GitHub Discussions or a
public Notion space so contributors can follow the reasoning. Before the restructure,
Eugen was juggling everything from code reviews to harassment reports—there was no
sustainable separation of duties. Projects like Mastodon grew healthier when they
defined working groups for moderation, infrastructure and community, instead of
relying on late-night DMs with the founder.
Speaker 1: When projects hit enterprise scale, they often seek a foundation or fiscal
sponsor. That legal wrapper handles trademarks, bank accounts and insurance while
letting maintainers stay focused on the code. Foundations typically set up a board plus
a technical steering committee, which keeps roadmap authority with engineers but
adds accountability and succession planning.
Speaker 2: Membership tiers and contributor licence agreements might feel
bureaucratic, yet they unlock grants, corporate dues and formal code of conduct
enforcement. Think about the CNCF or Apache—they provide neutral infrastructure,
security audits and marketing muscle, which are hard to sustain as volunteers once
Fortune 500 companies depend on your project.
Speaker 1: How do you know it’s time to formalise governance? Look for pain signals:
unresolved security issues piling up, companies asking for roadmaps, or maintainers
cancelling holidays because no one else can cut a release. A short community health
survey and retrospective can surface exactly where decisions or support structures are
breaking down.
Speaker 2: From there you can choose the right scaffolding. Maybe you just need a
fiscal sponsor like Open Collective Foundation to handle money, or maybe incorporating
a nonprofit makes sense. Include survey questions such as “How long do security
patches typically take?” or “Do you feel comfortable challenging technical decisions?”
so you track change over time. The important part is to document the decision criteria
and invite feedback so people understand the “why” behind the change.
Speaker 1: Governance work opens up real career paths: community managers, release
engineers, program officers inside foundations, even policy advisors specialising in
Indigenous data sovereignty. Ratios help with planning—aim for roughly one
community manager per two hundred active contributors, otherwise moderation and
onboarding slip.
Speaker 2: These roles suit people who can facilitate debate, document decisions and
build inclusive processes across time zones. Many start with a contributor streak, a
Google Summer of Code placement or a rotation through an open-source program
office. Hit that 200-contributor mark and, sure, your side project headaches
multiply—but they’re the good kind that signal your impact. Over time you might chair
the technical steering committee or move into an OSPO leadership role. The takeaway
is simple: intentional governance lets projects grow without sacrificing their values.
Community Tech Lead Role
Speaker 1: Our opener frames community tech-leads as connective tissue because they
sit between governance, engineering and contributor care. Once a project grows past a
couple dozen maintainers, somebody has to watch the whole ecosystem.
Speaker 2: Right, otherwise RFCs stall, moderation escalations slip, and users lose trust.
That ratio call-out—one tech-lead per 150 to 250 active contributors—gives learners a
benchmark for when to lobby their foundation for funding the role.
Speaker 1: On the responsibilities slide we emphasise facilitation as much as technical
leadership. Tech-leads host backlog triage, shepherd RFCs and ensure incident
responses loop back into documentation.
Speaker 2: And they are the culture keepers. Calling out inclusive communication,
mentorship pipelines and reporting to sponsors signals that this role is accountable to
people, not just code.
Speaker 1: The bridge slide paints the tech-lead as translator—turning localisation,
Indigenous data sovereignty requirements and user research into engineering tickets.
Speaker 2: Exactly, and the workflow slide anchors that translation in a daily cadence.
Learners see how office hours, merge queue triage and mentoring rosters all live on the
same calendar.
Speaker 1: For pathways we wanted to show this isn’t a mysterious promotion—you can
come through long-term contribution, fellowship programs or corporate OSPO rotations.
Speaker 2: Including iwi digital innovation hubs reinforces that Indigenous technologists
belong in these roles. The 4 to 6 year experience band sets expectations for skill depth
without gatekeeping specific degrees.
Speaker 1: The skills slide leans into empathy, multilingual communication and systems
thinking because tech-leads spend most of their time orchestrating people, not just
writing code.
Speaker 2: We also highlight calm incident facilitation and documentation-first
habits—those are the traits that reduce burnout and make governance transparent to
new contributors.
Speaker 1: The team slide shows how tech-leads partner with community managers,
legal counsel and accessibility experts. It grounds the abstract role in a concrete
staffing model.
Speaker 2: Calling out stipend advocacy and data-sharing up to boards also keeps the
justice lens present—tech-leads are accountable for equitable recognition, not just
sprint velocity.
Speaker 1: For progression we mapped a lattice: maintainer to tech-lead to ecosystem
leadership, with lateral moves into OSPOs, developer relations or policy work.
Speaker 2: That helps students see longevity—this isn’t a cul-de-sac role. It can lead to
foundation CTO seats or Indigenous data sovereignty leadership, which signals strategic
impact.
Speaker 1: We close by reminding learners that investing in tech-leads is about
sustaining trust and resilience, not just adding another title.
Speaker 2: Exactly—funding this role protects values, speeds reviews and keeps
governance tethered to community reality. That’s the north star for Part 7.
Foss Licensing Options
# Why licensing matters for open-source
Free and open-source software (FOSS) licences translate community values into legally
enforceable rules. Without them, collaboration would rely on vague goodwill and
expose contributors to liability. Licences are what allow organisations to adopt
community-built code with confidence, knowing the obligations they are accepting.
They also give developers a say in how their work can be used commercially,
redistributed or integrated into proprietary platforms.
Lack of clarity is risky. Something as small as copying an unlicensed JavaScript helper
into your start-up's product can trigger a cease-and-desist or a demand to publish your
whole codebase. Most licence disputes settle quietly, but the disruption, legal fees and
damaged trust are real. Thinking about licensing early lets teams align technical
strategy, community aspirations and compliance guardrails before launch day.
Remember: a licence is both a legal instrument and a social contract. Picking the right
one signals whether you prioritise frictionless adoption, reciprocal sharing, commercial
sustainability or a mix via dual-licensing. The rest of this module walks through how to
make those trade-offs without losing sleep—or receiving surprise letters from law firms.
# Permissive licences: flexibility with light obligations
## What they grant and require
Permissive licences such as MIT, BSD and Apache 2.0 grant broad rights to use, modify
and redistribute code with minimal restrictions. The non-negotiables are preserving
copyright notices, including the licence text and avoiding liability claims against the
authors. Apache 2.0 goes further by granting an explicit patent licence and a retaliation
clause—if someone sues you for patent infringement over the project, they lose the
right to use it. Some maintainers even publish small snippets or datasets under CC0 to
effectively place them in the public domain where law allows, reducing friction for
adopters.
## Why companies flock to them
Because these licences allow closed-source derivatives, they are popular with start-ups
building commercial services, vendor integration teams and digital agencies embedding
open libraries into client solutions. Think of React.js: Facebook chose MIT so product
teams across the globe could build proprietary apps without asking permission. For
early-stage ventures, the low compliance overhead and patent protection make
permissive licences feel like default safe bets.
The trade-off is reciprocity. You cannot force improvements back upstream, so
sustaining momentum depends on community goodwill, a healthy governance model
or, in some cases, parallel commercial offerings. Tools like choosealicense.com or
GitHub’s repository settings can guide first-time maintainers through the fine print
before they click “public”.
# Copyleft licences: reciprocity to sustain openness
Copyleft licences like GPLv3, LGPL and AGPL require that derivative works remain under
the same licence when distributed. This “share alike” obligation is deliberate: it keeps
improvements flowing back to the commons. Picture it like a viral clause—once your
code touches GPL components and you ship it to customers, openness spreads to the
whole bundle.
That does not mean every integration is doomed. The LGPL allows dynamic linking
without relicensing your proprietary app, as long as users can relink to updated library
versions. The AGPL closes the “software-as-a-service” loophole by treating network
access as distribution. Android handset makers learned this the hard way: because the
Linux kernel is GPLv2, device vendors must publish their modified source whenever
they release a firmware image.
Copyleft rewards collaboration-heavy ecosystems such as public-sector platforms, civic
tech or companies like Signal that want privacy features to remain inspectable. The key
is operational discipline—track what licences flow into your builds, and brief
stakeholders on when obligations trigger so surprises do not crop up the night before a
launch.
# Matching licences to organisational strategy
Selecting a licence is a cross-functional decision. Start by mapping goals: are you
optimising for adoption, reciprocity, revenue or community trust? An open-source
program office (OSPO) can facilitate a quick decision flow—permissive for growth
flywheels, copyleft for guaranteed sharing, dual-licensing when you need both
community momentum and commercial income. Keep a simple compatibility matrix
handy so you avoid mixing a GPLv2 dependency with Apache 2.0 code at the eleventh
hour. Projects like MySQL and Qt famously combine GPL for community users with paid
commercial terms for enterprises, while MongoDB’s shift to the Server Side Public
License (SSPL) shows how licence changes can protect a cloud business model.
Walk through a scenario: a government agency builds a records platform. They want
vendors to contribute back fixes funded by taxpayers, so the OSPO recommends GPLv3.
Legal reviews how contributions will be accepted (via Developer Certificate of Origin
plus a contributor licence agreement) and comms teams set expectations with
suppliers. Documenting the rationale up front prevents heated debates three years
later when a new contractor joins.
The human side matters too. Choosing a licence is like drafting a roommate
agreement—if you skip the tough conversations about chores (obligations) and guests
(governance), you will argue when mess appears. Bring in legal counsel, community
tech-leads, security engineers and product managers early, agree on international
implications (governing law, data sovereignty) and schedule regular reviews as your
project grows.
# Staying compliant in practice
Maintaining compliance requires disciplined processes. Developer advocates teach
engineers how to attribute dependencies within documentation and user interfaces.
Build engineers automate software bill of materials (SBOM) generation to prove which
licences are in use, then wire scanners into CI so incompatible combinations fail fast.
Licence compliance is a bit like flossing—boring when everything seems fine, but
skipping it leads to painful audits later.
Record every redistribution moment: shipping binaries, publishing container images,
even offering a SaaS endpoint that incorporates AGPL code. Keep source archives
ready, bundle NOTICE files and track third-party attributions in release notes. Several
high-profile companies have paid settlements for overlooking these basics, so treat
“we’ll fix it post-launch” as a red flag. Tools like FOSSA, OSS Review Toolkit or GitHub’s
dependency review can save hours once configured.
Finally, coordinate legal artifacts. Store signed contributor licence agreements (CLAs),
Developer Certificate of Origin (DCO) acknowledgements and export-control
assessments alongside your SBOM. That unified paper trail makes due diligence for
clients, investors or acquirers straightforward—and shows professional maturity in
handling open-source obligations.
## Career pathways and talent profile
Open-source program office (OSPO) analysts usually sit inside digital governance or
architecture teams and represent roughly 5–10% of the broader engineering operations
headcount in large enterprises. Most step into the role after five to seven years in
software engineering, developer advocacy or technology law, bringing credibility with
both coders and legal stakeholders. Personality-wise they need to enjoy meticulous
documentation, value fairness and possess the diplomacy to resolve conflicts between
community expectations and commercial pressures.
Entry pathways range from community contributors who have earned maintainer trust,
to compliance interns rotating through procurement, to dual STEM-law graduates hired
into tech policy teams. From there, practitioners can progress to OSPO managers
coordinating licence strategy across business units, and ultimately to director or VP
titles responsible for ecosystem partnerships and ethical technology commitments.
# Key takeaway
Thoughtful licence selection is a strategic lever. It signals how you invite collaboration,
protect contributors and align with Indigenous data sovereignty commitments when
projects intersect with cultural knowledge. Teams that understand obligations around
reciprocity, international law, CLAs and dual-licensing can design respectful contribution
models and sustain long-term trust with communities, customers and partners.
Maori Case Study
Speaker 1: We wanted a case study that shows Indigenous communities leading their
own digital futures, not being passive data subjects. Te Hiku Media is perfect because
it’s iwi-owned, rooted in te ao Māori values and has built genuinely world-class AI tools
while keeping sovereignty over the language assets.
Speaker 2: Exactly. Their work illustrates that “open” doesn’t have to mean “public
domain.” They use openness strategically—sharing with whānau, iwi partners and
trusted researchers—while still protecting taonga. It gives us a concrete example of
cultural protocols shaping a modern machine learning program.
Speaker 1: The organisation started as an iwi radio network in the Far North. Because
they’ve been recording kaumātua voices for decades, they hold archives that Silicon
Valley can’t replicate. When tech giants offered compute credits in exchange for the
data, Te Hiku pushed back—they wanted partnership, not extraction.
Speaker 2: Right, and that refusal is significant. Instead of chasing the fastest growth,
they prioritised mana motuhake—self-determination. They sought funding from Māori
trusts and philanthropies aligned with language revitalisation. That let them set terms
before letting anyone access the corpus.
Speaker 1: Their governance model is anchored by the Kaitiakitanga licence, which
literally says the data is a treasure held in trust for present and future iwi members.
Any partner has to demonstrate reciprocity and cultural safety before touching the
language assets.
Speaker 2: And that’s backed by practice. They run hui where linguists, kaumātua and
technologists review project proposals together. If whānau aren’t convinced the
outcomes will uplift communities, the project pauses until the concerns are resolved.
That blend of tikanga and agile delivery is what keeps sovereignty intact.
Speaker 1: The recording sprint they ran in 2019 is legendary—community members
lined up to donate sentences in kura, marae and community centres. They paired each
session with kai and cultural briefings so people understood where their voices would
go.
Speaker 2: The tech team then built a custom labeling tool because mainstream
platforms couldn’t handle dialect nuances. They co-designed prompts with linguists to
capture dialectical diversity, not just “standard” te reo. Contributors kept moral rights
and could revoke samples, which is unheard of in most corporate datasets.
Speaker 1: From a technical perspective, they forked Mozilla Common Voice to
jump-start infrastructure but stripped anything that conflicted with Māori governance.
Storage sits in AWS Auckland zones with encryption keys controlled by Te Hiku, and
every data access is logged for auditing by the board.
Speaker 2: The roles are interesting too. They formalised “data kaitiaki”
positions—people fluent in te reo who also understand privacy law. These staff sign off
on data queries and review model outputs for cultural harm. It’s a career path that
blends community leadership with product management skills.
Speaker 1: When global vendors came knocking, Te Hiku insisted on memoranda of
understanding that detailed reciprocity. That included commitments to fund language
revitalisation, keep infrastructure in Aotearoa and allow Te Hiku to veto secondary uses.
Speaker 2: They also built tikanga clauses into the contracts—staff had to attend
cultural safety training, and models couldn’t be repurposed for surveillance. Every
partnership was staged with opt-out checkpoints so the community could walk away if
promises were broken.
Speaker 1: The tangible results are huge. Automated transcription now captures iwi
radio archives in hours instead of months, and whānau can search recordings for tīpuna
names. The speech models achieved massive accuracy gains because they were
trained on dialect-specific data.
Speaker 2: Plus, the wider Indigenous tech movement took notice. Te Mana Raraunga
referenced Te Hiku’s licensing approach when drafting national Māori data governance
principles. Alumni from the project have moved into senior roles across government, iwi
corporations and platform co-ops.
Speaker 1: So what should our learners copy from this? First, invest in cultural
authority—make sure kaumātua, elders or cultural experts are leading alongside
engineers. Second, treat licences as living documents that express consent and
reciprocity, not just legal fine print.
Speaker 2: And build career ladders. Roles like data kaitiaki, Indigenous product
managers and kaupapa-aligned cybersecurity leads should have progression into senior
leadership. Success metrics need to include community benefit and language vitality,
otherwise the tech will drift away from its purpose.
Speaker 1: That wraps the Te Hiku kōrero. Take a breath, capture the lessons, and then
we can zoom out to mainstream open-source governance with fresh eyes—treat it as a
separate toolkit you can compare and contrast, not as something that replaces the
tikanga-led model we just explored.
