A couple of thoughts: Podlings are not permitted to call themselves "Apache Foo" because they are not yet full Apache projects.
While in the incubator we should expect podlibgs to fail at the rules. They're new to them and many of them feel arbitrary, even capricious, to those coming in from outside. We should make it safe to fail until they are ready to graduate. We should nurture them as long as they are moving towards that goal. I cannot disagree with your reading of our resolutions. But I wonder if that reality is producing good citizen projects or a bunch of resentful people following rules they don't understand or embrace because they know they have to. Zipkin is only the latest project which clearly didn't get it and has left angry. I would rather a project realize that they don't fit and be able to leave with their dignity without having also to leave hating what we stand for. I want our new graduates to love and understand the ASF not merely tolerate it. I want the incubator to respond to failure with gentle correction rather than scoldings. Specifically I think podlings should be able to produce releases that are not asf complient and have them clearly labeled as such. Because they are not TLPs yet and so cannot be held to the same standard. This must be accompanied by a movement towards being a TLP, not some eternal incubation. The incubator should be a mentor - an educator - not a jury. On Fri, Jun 21, 2019, 01:04 David Nalley <da...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
