Applying the Apache Way to Emerging Technology

Purpose

This guidance exists to help PPMCs make well-governed decisions about new tools, platforms, and workflows without adding policy or drifting away from established ASF values.

Context:
From time to time, ASF projects encounter new tools, platforms, or workflows that trigger uncertainty, strong opinions, or other reactions.

These discussions often follow a predictable pattern:

• the change is framed as a threat to ASF values,
• hypothetical legal risks are amplified,
• calls for new rules appear quickly,
• and only later do people rediscover that the existing ASF policy already covers the situation.

Scope

This guidance is intended for Podling PPMCs. It focuses on how projects should evaluate, adopt, and govern new tools, platforms, and workflows in ways that are consistent with ASF values and existing policy.

Key PPMC Lesson

Before escalating concerns about a new tool, platform, or workflow, projects should always first locate and understand the existing ASF policy and governance mechanisms.

In most cases:

• The ASF’s legal and governance framework already applies.
• New tools rarely require entirely new rules.
• The real governance work happens at the project level, not through Foundation-wide bans or ad-hoc controls.

ASF Values as a “Policy Multiplier”

One of the reasons the ASF governance model has held up for 25+ years is that:

• ASF values are stable
• Technology changes constantly
• Formal policy evolves slowly and deliberately

This means that, in practice:

New tools, platforms, and workflows are usually governed first by values and existing project processes, not by new rules.

This is true for:

• cloud hosting,
• containers,
• CI/CD,
• GitHub,
• new distribution platforms,
• and generative AI.

Values Before Rules (Core Principle)

When a new tool, platform, or workflow appears, projects should apply ASF values first and seek new policy only if those values can no longer be upheld under existing rules.

The ASF’s values and core governance model are intentionally stable and have proven to apply across multiple decades of technological change. In most cases:

• New tooling is already covered by existing values and policy
• The Apache Way continues to apply without amendment
• Only rare edge cases (typically involving privacy or new laws) require substantive policy updates

Projects should assume durability first, and only revisit policy when real, demonstrated gaps appear in practice.

Example: A New Distribution Platform

When a new distribution platform appears, projects typically should not start by asking:

• “Do we need a new Foundation-wide policy?”

Instead, the PPMC should apply existing values and rules:

• Openness - Is it publicly accessible?
• Vendor neutrality - Are we locked into a single provider?
• Reproducibility - Can releases be independently verified?
• Infrastructure policy - Does it align with ASF infrastructure guidance?

In most cases:

• the existing policy already fits,
• and if it doesn’t, that gap becomes visible through practice, not speculation.

Exactly the same pattern applies to generative AI and other emerging tools.

What PPMCs Should Role-Model

PPMCs should demonstrate:

• Policy grounding before speculation
• Calm framing instead of fear-driven escalation
• Separation of legal facts from personal values
• Respect for existing ASF safeguards (ICLA, PPMC review, release process)

PPMCs that react with alarm unintentionally:

• discourage participation,
• create confusion about ASF expectations,
• and undermine trust in established governance.

Example Language PPMCs Can Use

“ASF policy already applies here. Whether code is written by hand or with assistance, the contributor is responsible for provenance, and the PPMC is responsible for review. Let’s focus on the quality and compliance of the contribution itself.”

What PPMCs Should Avoid

• Treating new tools as automatically “dangerous”
• Inventing new process rules before confirming policy gaps
• Framing speculative legal risks as threats
• Shifting responsibility away from human review
• Creating compliance theatre (checkboxes, declarations, unverifiable attestations)

Reflection Question for PPMCs

When a new tool or workflow feels disruptive or threatening, how can the project tell whether it is responding to real policy risk?

Important Exception: Privacy and Irreversible Risk

While the ASF generally applies values first and policy only when necessary, there are cases where the Foundation does impose explicit bans. These are almost always driven by:

• Privacy and personally identifiable information (PII)
• Data protection laws and regulations
• Irreversible harm once information is leaked
• Legal exposure that cannot be mitigated through normal review

Examples include:

• Restrictions on handling private data
• Limitations on using third-party platforms that violate privacy expectations

In these cases:

• The risk is not speculative
• The harm is not reversible
• And policy must be explicit and enforceable

When these conditions appear, projects should seek advice rather than attempt to resolve them on their own.

When PPMCs Should Escalate

Most emerging tool, platform, and workflow decisions are resolved entirely within the PPMC. Escalation is the exception, not the norm.

PPMCs should escalate beyond the project when:

• There is credible privacy or personal data exposure
• There is likely a license incompatibility that cannot be resolved
• There is uncertainty about distribution rights
• The project proposes to store, process, or transmit user data externally
• The risk is irreversible if a mistake is made

In these cases, escalation to the IPMC, ASF Legal, or ASF Infrastructure is appropriate before proceeding.

Safe Experimentation Model

PPMCs should be encouraged to:

• Start with non-critical paths (tooling, analysis, CI, documentation)
• Avoid first use in release-critical workflows
• Keep experiments opt-in and reversible
• Document assumptions and outcomes publicly
• Review outcomes before expanding use

This allows innovation without binding the project or ASF to fragile decisions.

Automation, CI, and Repository Access

While ASF projects may use automation and CI systems extensively, write access to ASF repositories is restricted to human committers only.

This means:

• Bots and external automation tools must not hold commit or write access
• All changes must ultimately be authored, reviewed, and merged by an identified human committer
• Accountability for every change always rests with a person, not a tool
• CI systems may test, validate, or report, but they do not decide or commit

This control ensures that:

• The ASF’s accountability model remains intact
• The ICLA continues to have a clear legal meaning
• Review, intent, and responsibility remain human-centred

For emerging technologies, including AI-assisted tooling, this principle must always be preserved.

Choosing the Right Venue for Emerging Technology Discussions

• Project dev@ lists: Implementation details and experiments
• PPMC private lists: Risk assessment and early concerns
• IPMC lists: Cross-project patterns and Incubator-wide implications

Foundation-wide venues (such as Members@) are not normally part of the PPMC escalation path.

What Good Looks Like

A project has successfully navigated an emerging tool, platform, or workflow when:

• Use is transparent and documented
• Provenance and compliance remain intact
• Contributors understand expectations
• No single vendor controls access or direction
• The project can stop using the tool without structural harm

Projects that demonstrate this level of disciplined, values-aligned decision-making generally show stronger graduation readiness, as they can adopt new technology without compromising governance, independence, or compliance.

Early Warning Signs for PPMCs

PPMCs should increase scrutiny when:

• Contributors avoid discussing how tools are used
• Decisions are made on private chats or vendor platforms
• Tool access becomes required to contribute
• Release processes become opaque
• Legal or provenance questions are dismissed as “slowing us down”
• A single vendor begins to control access to critical tooling or infrastructure

Project Framing

“ For most new tools, platforms, and workflows, Apache values and existing processes are the first line of governance.”