incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davor Bonaci <da...@apache.org>
Subject Re: Podlings, the Incubator, relationships and Apache
Date Thu, 20 Jun 2019 17:20:03 GMT
I second every single sentence said here. Every. Single. Sentence.

On Thu, Jun 20, 2019 at 10:04 AM David Nalley <david@gnsa.us> wrote:

> There's been a lot of discussion in various threads about bureaucracy,
> whether podlings are part of the ASF, etc. As a result of that I've
> spent a good deal of time reading resolutions and older discussions
> and organizing those thoughts from a legal and community perspective.
> I've also read a number of conversations from the more august members
> of our body about this subject. Altogether it has somewhat changed
> some of my opinions and assumptions. I've also sensed that there is a
> community/business/legal disconnect in our conversations. We're using
> the same words to mean very different things in each of those
> contexts. That said I am but one member of the IPMC, but maybe this
> will be helpful to someone else - I've tried to avoid my assumptions
> in this.
>
> The IPMC's first 'job'[1] is "accepting new products into the
> Foundation" The second 'job' of the IPMC is to "provide guidance and
> support to ensure that the Incubator's sub-projects[2] develop
> products according to the Foundation's philosophy and guidelines". The
> final 'job' is evaluating the products and determining whether they
> should be abandoned, continue to receive guidance and support, or be
> promoted to "full project status".
>
> So there are several realizations I gained from this from the
> Incubator perspective.
> 1. Acceptance into the Incubator is acceptance of the product into the
> Foundation.
> 2. That product is then a sub-project of the Incubator.
> 3. The IPMC has the "primary responsibility for the management of
> those subprojects".
>
> From the Foundation's perspective there are a number of things that
> come to mind:
> 1. We aren't a github/sourceforge/google code type platform where
> random people can upload/post what they want.
> 2. We do not have DMCA Safe Harbor protection - e.g. we are
> responsible for everything that we publish or distribute. With the
> exception of wikis and bug trackers anyone who can put something up on
> an Apache property has some form of legal relationship with the
> Foundation. This could be as simple as an ICLAs where you've
> contractually said you won't contribute anything you don't have rights
> to.
> 3. Most of the project's who have come to us aren't entities in and of
> themselves. E.g. the 'project' doesn't truly exist from a legal entity
> perspective - and even those who do are at best an unincorporated
> association of individuals. From a legal perspective - projects can't
> make or distribute a release - they don't exist - only the ASF and the
> individual(s) doing the work. Given that one of the explicit reasons
> the Foundation was created was to[5]: "provide a means for individual
> volunteers to be sheltered from legal suits"; we want them to create
> and distribute releases as the Foundation.
> 4. Whether we like it or not - the Foundation is judged on the output
> from our projects and subprojects. We have a reputation of having
> clean IP, permissively licensed open source code, with clear
> provenance. Many people explicitly copy our standards, guidelines, and
> policies because they are the gold standard for good open source
> governance.
> 5. Disclaimers generally don't remove liability, and even if they did,
> our disclaimer talks about the maturity of our projects. - And it
> certainly doesn't remove the public's expectations from us - frankly -
> losing the publics trust is as scary as the potential legal liability.
> 6. The Board has delegated the responsibility of managing and ensuring
> adherence to policies and guidelines to the IPMC. I don't see this
> responsibility as boolean. It's not perfect compliance vs. failure.
> IMO, the IPMC has been delegated the decision making process, and may
> often find themselves making the business decision that an imperfect
> release is better than a community stalled for months or years. Don't
> let the perfect be the enemy of the good.
>
> From a podling's perspective:
> 1. Once you join the incubator you're a part of the ASF (Yay!?)
> 2. Your project is now a subproject of the IPMC.
> 3. There are rules, and you're entering a world of pain[4] In fact,
> you're likely to find that the ASF has more rules and structure that
> apply to projects than virtually any other home your project could
> choose. This is good and bad.
> 4. The incubator has a long, storied history of producing successful
> projects that flourish.
>
>
> [1]
> http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
> [2] What we call Podlings, the initial resolution refers to as
> subprojects of the Incubator
> [3] It's worth noting that there were two resolutions proposed to
> create the Incubator - small differences, but interesting to read the
> differences.
> [4] https://youtu.be/3vB9U2hx6Qg
> [5] https://www.apache.org/foundation/faq.html#why
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

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