On Tue, Oct 25, 2016 at 3:50 AM, Isabel Drost-Fromm <isa...@apache.org> wrote: > Pre-text: This conversation started among several members of the ASF, you are > seeing this message here, as it was suggested to have the discussion on a > public mailing list so everyone can participate. > > > Hi, > > tl;dr: I'm tired of hearing Apache is "where large firms dump code (to break > the > market for other or to avoid looking bad for abandoning it", I'm also tired of > hearing that Apache is where projects are controlled by corporate interests > under the disguise of some Apache Way process. I would like to figure out > whether this is actually true based on numbers instead of subjective > perceptions. If it is true I would like to figure out if and how we need to > fix > this.
Unfortunately, for matters like these, perception = reality. Facts and figures won't easily change those perceptions. > Longer version: Every now and then I hear people complain either privately or > publicly [1] that people working on Apache projects who are not paid to do > that > work and have don't have the luxury to participate full-time are facing a hard > time getting into our communities. Some projects have higher bars than others. If the net effect of a higher bar is to exclude those that can only afford to contribute on their own time, then we should address that -- on a case by case basis. > Similarly every now and then we see projects running into trademark issues, > conflicts of interest with their employers, trouble with wearing too many hats > [2,3] (though everytime I hear about wearing more than one hat I have to think > of the following lightning talk [4]). > > I don't think handwavery statements will get us very far. Maybe it makes sense > to think about the following first: > > - If projects are making progress (getting new releases out, getting new > features implemented, getting bugs and security vulnerabilities addressed), > do > we care about how they are governed? Why do we care if we do? About which > aspects do we care? We very much do care. To illustrate: I work for a large company where cluefullness is not evenly distributed. Once (in the now distant past), a group was referred to me for advice on how to approach the ASF. The conversation started with that individual expressing a desire to control the content of the product, who was and was not allowed to contribute, and what license the code was released under. The conversation ended with me saying that they don't want to come to the ASF. At the time, I directed them to SourceForge. These days, I would have suggested GitHub. > - Given the influx of projects into the incubator (and the number of projects > making it through) people seem to trust the ASF as a home for their > communities. What kind of value does that have for us? What is the value we > are giving back to these projects? >From my perspective, I see the growth as evidence that people value our model of governance, our license, and our brand. As for your last question, I don't see us having any obligation to give back to those that don't value our model of governance, our license, and our brand. > Maybe from there we can come up with stories and metrics that hold (or should > hold) for all of our projects. +1 for stories -0 for metrics > Let me provide an example for illustration: In many previous conversations and > talks I stressed that Apache is about communities, that being part of an > Apache > project doesn't necessarily mean that the particular human has to contribute > large amounts of code - in the case of Mahout at some point we even had to > communicate that the best way to not be accepted as a GSoC student would be to > propose to implement yet another machine learning algorithm as that would > probably not what the project needed most, nor would it be feasable given the > time frame. Based on that my answer to "do we care about how projects are > governed" would be "yeah, sure we do - our system is based on merit, merit > comes > from valuable contributions". The metric I'd setup to test that hypothesis is > true would be to cross-check number of contributions (patches, documentation > fixes and the like) with whether the people making these contributions are > actually being promoted to committer. Makes sense? Again, this varies too widely between projects to make comparison meaningful. Some projects give out committership like candy (I tend to lean this way). Others have a more rigorous definition of merit. As a rule of thumb, if a PMC has three independent and active members, added a PMC member within the past year, and made a release during that time and is not reporting any problems, then generally all is good from a board perspective. But these are not hard and fast rules, deviations from one or more can also be OK. And a project can meet these criteria and still be a problem. Like others, I see metrics as an aid, not an end in itself. If a project hasn't made a release in a while and hasn't explained why not in their quarterly report, then that is an indication that deeper research is required in to the health of the PMC. > Anyone interested in this? Anyone interested in helping get sensible numbers > up > - my JIRA magic is seriously lacking... The reporter tool tracks much of what can easily be gathered. It is good at what it does. And it has received criticism based on others taking that input and seeing that as more than a mere indicator. https://reporter.apache.org/ > Isabel - Sam Ruby > [1] > http://apache-spark-developers-list.1001551.n3.nabble.com/Spark-Improvement-Proposals-tt19268.html#none > > [2] > https://www.youtube.com/watch?v=F0DpP25QCfQ&list=PL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ&index=13 > > [3] > https://www.youtube.com/watch?v=26T-UKAs1Fk&list=PL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ&index=11 > > [4] https://www.flickr.com/photos/carlossg/4081471635 > > [5] > https://lists.apache.org/thread.html/76610c48321397e7af8e2e433ac73e6e1da4aa1a80b1fac67e7ed8c2@%3Cboard.apache.org%3E > > -- > Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most > likely involving some kind of mobile connection only.) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
