incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Poore <>
Subject Re: New disclaimer text
Date Thu, 11 Jul 2019 02:00:49 GMT

I’m also a PPMC member (Apache Flagon). It seems the Incubator is at an inflection point—been
tracking how different threads on general@ are capitulating on issues of identity and process.
Gian’s points are SPOT on, but so are Justin’s. I have some reconciliatory thoughts and
suggestions, which I’m embedding in line:

> On Jul 10, 2019, at 5:44 PM, Justin Mclean <> wrote:
> Hi,
>> Speaking as a member of a currently-incubating project (Apache Druid) where
>> we have always strived to do releases with no known licensing issues, the
>> text sounds needlessly scary to downstream consumers.

> And that may be the problem with a one solution fits all process. It has been suggested
before we let podlings choose which release process they want.  However that may get too complex
and make voting on releases inconsistent.

+1 on both points. The value we (podlings) take out of the Incubator is mentorship and scaffolding
in adopting the Apache Way. In doing so, the “Way”, its processes, and the policies that
shape those processes are meant to improve our offerings (code), our adoptability, and grow
a sustainable community. Adding an additional disclaimer that we may have known issues adds
additional barriers to adoption and community growth. An Incubator by definition takes on
risk—infrastructure, time,  and opportunity, sunk, and operational costs—to help nurture
its participants. That risk is directly yoked to the participants’ value gains from participating.
Placing additional barriers to growth and adoption to eliminate the ASF’s risk breaks the
incubator model altogether. 

>> IMO this disclaims too much, and would chill adoption of incubating
>> software by people that care about having clean licensing. PPMCs should be
>> able to say "we believe this release is clean and have vetted it using a
>> normal Apache vetting process" or maybe even "we have vetted this release
>> and it is clean other than the following list of known issues". If they
>> can't say one of those two statements, then maybe it's not time to do their
>> first release yet.
> The idea is to allow podlings to make releases that may not comply with policy. Have
a hard switch from your releases doesn’t comply to everything must comply is too difficult
for some podlings.

+1 on both point and counterpoint. This disclaims too much and there needs to be compliance
to policy. The risk the Incubator needs to take is that 100% compliance is an eventual, but
measurable goal. Yet, the Incubator needs a means to manage risk. A better model than the
disclaimer: progressively incentivize compliance with metrics. 

Here’s one way for the ASF Incubator: Apache’s key marketing point is the Apache Way.
Break down critical processes, determine key performance indicators against those processes,
and centrally track metrics (license compliance, community participation, release compliance,
notice, keys, whatever, whatever). Then build some Apache-branded badges that expose those
metrics publicly so that all your podlings can stick them on their GitHub READMEs, same way
as we have for CI, test coverage, etc., etc. Doing something like this, the Incubator is using
the brand to incentivize organic compliance and manage risk. Implicit in this usage of the
Apache brand is communication that podling projects are not fully endorsed by Apache, but
the project being looked after by a trusted organization. Podlings have clear metrics that
they can communicate and take actions to move the needle on. Podlings have a way to discriminate
themselves from other open-source projects and from other podlings by showing positive values
on their badges. This whole model provides a discriminator for all podlings in that other
open-source projects don’t have the infrastructure to communicate these metrics; these badges’
existence engenders trust in the ASF & Incubator brand(s) and skepticism about non-Apache
projects. Podlings who work to budge metrics can communicate to consumers and potential community
members and continually brings them in line with Apache policy—the value they get from the
incubator is now directly proportional to compliance (Incubator risk reduction). The Incubator
also gets a better way to track incubation status, direct special attention to podlings that
are bottoming out (before removal) and podlings that are showing progressive improvement.
This method (or similar) tells the public how much trust Apache has in a particular podling.
The additional disclaimer communicates that Apache has little trust in its podlings, at large.

Maybe this is too much technically (I doubt that), maybe this isn’t the best or only way
to do this, but the key theme here is: measurable, progressive improvement. That should be
sufficient to stay in the Incubator and necessary to graduate. Importantly, “progressive”
means that metrics are updated regularly and not just at the time of release... 

>> And yeah, as a few others have mentioned, I believe that a more streamlined
>> voting process
> That I think is a different issue, ands may be best to start another thread on that.
The main issue here is that IPMC members votes are binding, and not all mentors (who are IPMC
members) vote on releases, so podlings need votes from the wider IPMC members to make releases
(in about 90%+ of cases). There been a few ideas on how to improve this, including one approved
method (but no podlings have take that up yet).

-1. These are connected issues: Mentors are IMPCs "tip of the spear" for managing compliance
risk and for adding value to podlings. I have so much respect for Justin and other IPMC regulars
who tirelessly volunteer and monitor general@, dig into minor releases to test builds and
check compliance. It’s heroic, but heroes are a sign of struggling operations in orgs, and
heroes burn out. Their valuable time is better spent institutionalizing knowledge and skills:
making mentors' jobs easier with templates, documentations, infrastructure projects. In doing
so, the Incubator empowers PPMCs, engenders self-sufficiency and gives mentors bandwidth to
progressively track compliance at regular intervals, VOTE on releases (with expediency), swoop
in to help with the tactical issues that come up, and actually mentor podlings on how to steadily
grow with wisdom and experience.

IMHO: the thing the needs to be discussed in a different thread is how the Incubator supports
and incentivizes engaged mentors. Speaking from experience: engaged mentors are magical gifts
from above. Losing mentors during critical junctures is terrifying because there is so much
to learn and its hard to find documentation and examples for how to do things right. Its hard
to know what you have permission to do and taking a risks to do certain things without mentors
can result in shame and worry that you’ll look like you're struggling if feel they're done
wrong. These issues are inexorably intertwined because mentors are at the heart of managing
Incubator risk/compliance and value to podlings.

Ever chasing the Apache Way,


> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message