You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Isabel Drost-Fromm <is...@apache.org> on 2016/10/25 07:50:21 UTC
On wearing multiple hats
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.
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.
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?
- 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?
Maybe from there we can come up with stories and metrics that hold (or should
hold) for all of our projects.
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?
Anyone interested in this? Anyone interested in helping get sensible numbers up
- my JIRA magic is seriously lacking...
Isabel
[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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Shawn Heisey <ap...@elyograg.org>.
On 10/25/2016 1:50 AM, Isabel Drost-Fromm wrote:
> 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.
I'm a committer on the Lucene-Solr project, working primarily on the
Solr part. I've had this role for about 3.5 years. I am not a member
of the PMC.
The committer invitation came completely out of the blue. Before that,
I had contributed a few patches via Jira, and some of them had even been
committed, but my biggest participation is being active on the Solr
mailing list and IRC channel. I maintain Solr installations as part of
my job, but nobody has ever paid me for the work I do on the project,
and my employer has never made any demands of me in my role as
committer. I definitely cannot work on Solr full-time. I enjoy
participating, and I like to think that I'm part of a good open source
community.
I think I can safely say that our project has several people who are not
paid for their project work, and do not have significant spare time to
work on the project. There are also a number of committers who DO have
jobs where I believe they are effectively paid to improve the project,
even if it's not a full job description. It's hard to say whether those
relationships represent conflicts of interest regarding the health of
the project. My cautious point of view is that there's no *immediate*
cause for concern with Lucene.
At least one of our committers knows almost nothing about Java, which is
significant because Lucene-Solr is a Java codebase. That person obtained
the role because of a strong willingness to help in other areas -- they
are active on the mailing lists, and they almost single-handedly
contributed a vastly superior Solr web interface before being invited as
a committer, using html, css, and javascript.
I'm not sure which Apache projects might fit the description you have
provided. I am subscribed to a few other Apache project mailing lists,
for other Java technologies that Solr includes as dependencies. Aside
from being far less active than the Solr community, those also appear to
work properly in the Apache Way like (IMHO) Lucene-Solr does.
Even if there are projects that work the way you have described, I'm
reluctant to endorse having the foundation "help" (read: interfere) with
their operation unless the project or its community specifically
requests it. That should be reserved for projects that are completely
broken, not projects that have a few internal issues to work out. If a
particular community feels that they have issues, I think it's mostly up
to that community (the PMC in particular) to make that determination and
deal with the problem.
All that said... there's likely room for improvement in some
projects/communities, even some that you'd say are healthy.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Phil Steitz <ph...@gmail.com>.
On 10/26/16 7:06 AM, Isabel Drost-Fromm wrote:
Thanks for sharing this, Isabel. I have a similar kind of personal
comment below, but I have to first say that my immediate reaction
reading about your experience was how lucky we are that you managed
to make it to that Acon :) Please thank that person for us!
> On Tue, Oct 25, 2016 at 02:19:06PM +0000, Ross Gardler wrote:
>> > First, I'm tired of hearing it too but let's not be fooled, most of the time it comes from people ill informed about how the ASF works.
> I have no doubt about that. Maybe we can do a better job telling people how we
> work then?
>
>> > We use social controls within the projects and we have a fully independent board to handle escalations should a community member feel that their (or anothers) merit not be recognized.
> Let me tell you a story to illustrate what kind of problem I see with that (and
> I'm happy to be told, that this is just me having that problem or not reading
> the docs):
>
> I came to the ASF when nutch went from sourceforge through the incubator to be a
> sub project of Lucene. Being the naive student I was I had no idea what this
> whole ASF thingy was - all I knew about was the web server in my Debian Woody
> distribution with the same name. I was blissfully ignorant to what kind of
> contributions would be welcome in the project and what merit I should gain
> through that.
>
> A year or two later I was a bit closer open source at Apache, I had subscribed
> not only to nutch but also to Lucene mailing lists. A learnt about a conference
> related to the projects close to where I was working back then - namely in
> Amsterdam. I looked at the ticket prices expecting to see something like FOSDEM,
> Chaos Communication Congress, Linuxtage or some such which I happened to know.
> But the prices were just way above and beyond anything I could afford. And my
> research group would only really pay for scientific conferences.
>
> Fast forward another year or two, I was working for a small company in Berlin
> (neofonie, back then doing search consultancy mainly), I
> had co-founded Apache Mahout, as a result I was entitled to get a committer
> discount. I asked my manager for vacation days to go - and got a "let me check
> if we can actually send you there on our cost" as a reply. Back at that Apache
> Con EU 2008 in Amsterdam was when I first understood some of the basic concepts
> of how things are supposed to work around here, what kind of contributions
> should be rewarded.
>
> Only much later did I come across books like Producing Open Source Software, did
> I watch several keynotes on how things work over at Debian and friends, did I
> read about C4 at ZeroMQ, did I see things like the "Poisonous People" video.
>
>
> To cut a really long story short: I may be mistaken, but I think even with the
> incubator community members may not even be aware of a lack of merit. Look at
> the thread over here:
>
> http://mail-archives.apache.org/mod_mbox/community-dev/201610.mbox/browser
>
> isn't that already showing that some questions arise only way after incubation?
>
>
>> > If this is breaking down then its a problem within the PMC not with the process, which has served us well for many years across many projects and should, IMHO, serve us well for many more. Rather than starting to look for a solution to a problem purebred by others perhaps we should look at why they have this perception.
> Just for the record: I don't think we have a process problem per se here. We
> might have an education problem: In terms of what (even if it's little) we
> expect from projects, in terms of what people should do when they see those
> expectations not being met, in terms of what is being done within the ASF to
> keep things in line (or phrased more bluntly: If everything goes wrong, what can
> you expect the board to do to your project? How did we educate projects in the
> past?)
>
>
>> > Here's my thoughts...
>> >
>> > Open source, in general, has changed. Its gone from mostly individual hackers from small collaborating companies "scratching their own itch" to mostly big business and will funded startups paying individuals who sometimes don't care on a personal level. This has resulted in the emergence of a different flavor of open source. One in which money and metrics count more than community and code. I'm the money and metrics model success means market disruption rather than collaboration on code.
> This matches with some of what I see as well.
Yes, there is no doubt that is has happened. I used to be really
worried about it and I even went emeritus at one point because I
thought the ASF was just becoming a shell for commercial software
ventures. I realized later that was over-reaction. That
over-reaction was the result of a naive view on how OSS was going to
grow and change the software industry and a lack of appreciation for
the remarkable resiliency of the ASF.
I came to the ASF as a user in 2002. I was a technology leader at a
large financial services company in the US and we were in process of
moving all of our web technologies and a lot of middleware services
to Java. We were getting a lot of help from two great technology
companies, whose names are easy to guess, both having long and
interesting relationships with the ASF. Both also, as Sam so
eloquently put it, had an uneven distribution of cluefulness
(nowhere dense, but definitely positive measure :). One of the
architects from the __ Java Centers pointed out to me that the
internal MVC framework that we had developed looked a whole lot like
Struts. That led me to start looking at the Struts code. I saw
that he was right; but Struts was better. At first, I just wanted
to see if it was something we could use and if so, figure out how to
support it; but that led to getting on the user list, then the dev
list ... and then that personal connection kind of kicked in.
What I saw at the time was a *huge* change in how software products
come to be and evolve. Instead of marketing strategies, legacy
products and commercial competition driving the agenda, it was going
to be users - people like me and my teams who actually use software
determining what gets built. I was coming off a string of painful
experiences with heavy application servers and middleware so I was
very excited that I might one day be able to stop pounding the table
with vendors, saying "Please, stop trying to get me to have the
problems that you have solved. Solve the ones that I actually
have." I was excited and did everything I could to encourage my
peers and the clueful ones inside $bigCos to engage in OSS
communities and adopt OSS software. At the same time, I started
contributing myself.
My attitude toward technology leadership has changed dramatically
during my time at the ASF. I saw that the core concepts of
transparency, community and meritocracy could be applied inside
organizations of all sizes and functions. I gave a talk about this
at Apachecon US 2008 [1].
All of that is background to what happened in 2011 when I realized
that my wonderful dream of "user-driven software" was colliding with
the reality that commercial software companies were not going away.
I was shocked to realize how many people were actually paid to work
full time on ASF projects. That could not be a good thing! Then I
came to realize who these people were. Some of the most wonderful
community members among us. And the companies that were paying them
- well, most appeared to actually accept the idea that investing in
an ASF project carries "control risk" and they were willing to take
that risk. Sure, some were idiots; but the ASF Board had this big
clue bat they could and would take out now and then to remind the
intransigent.
So yes, the nature of OSS has changed since the early
volunteer-dominated days and yes, this means that some people and
even entire project communities need to be reminded now and then
about what we mean by "separation of hats;" but as you and others
have pointed out, the core processes and structure of the ASF really
are robust against this and other changes in the dynamics of the
software industry. As long as we keep gently but firmly reminding
people that our communities have to be transparent and inclusive and
that ideas have to win on their publicly earned merit, we will keep
Greg's vision of a healthy ASF 50 years from now [2] alive.
Phil
[1] http://www.slideshare.net/psteitz/open-development-in-the-enterprise
[2] A cool feature of this vision is its evergreen nature - I think
he originally said it about 5 years ago :)
>
>> > I maintain that the Apache Way is still a highly valuable and repeatable process that when applied correctly brings the highest chance of success (where success is valuable open source code). It is a process that is designed to ensure that those who care on a personal level have as much influence as those who are motivated by external need. It is a process that leaves money and metrics at the door but recognizes community and code contributions quickly.
> The "recognizes *community* and code contributions *quickly*" is something I
> would like to see validated across communities. I'm pretty sure even Mahout is
> guilty of having waited long to hand committer status out to people who contribute
> on a non-Java-level.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Isabel Drost-Fromm <is...@apache.org>.
On Tue, Oct 25, 2016 at 02:19:06PM +0000, Ross Gardler wrote:
> First, I'm tired of hearing it too but let's not be fooled, most of the time it comes from people ill informed about how the ASF works.
I have no doubt about that. Maybe we can do a better job telling people how we
work then?
> We use social controls within the projects and we have a fully independent board to handle escalations should a community member feel that their (or anothers) merit not be recognized.
Let me tell you a story to illustrate what kind of problem I see with that (and
I'm happy to be told, that this is just me having that problem or not reading
the docs):
I came to the ASF when nutch went from sourceforge through the incubator to be a
sub project of Lucene. Being the naive student I was I had no idea what this
whole ASF thingy was - all I knew about was the web server in my Debian Woody
distribution with the same name. I was blissfully ignorant to what kind of
contributions would be welcome in the project and what merit I should gain
through that.
A year or two later I was a bit closer open source at Apache, I had subscribed
not only to nutch but also to Lucene mailing lists. A learnt about a conference
related to the projects close to where I was working back then - namely in
Amsterdam. I looked at the ticket prices expecting to see something like FOSDEM,
Chaos Communication Congress, Linuxtage or some such which I happened to know.
But the prices were just way above and beyond anything I could afford. And my
research group would only really pay for scientific conferences.
Fast forward another year or two, I was working for a small company in Berlin
(neofonie, back then doing search consultancy mainly), I
had co-founded Apache Mahout, as a result I was entitled to get a committer
discount. I asked my manager for vacation days to go - and got a "let me check
if we can actually send you there on our cost" as a reply. Back at that Apache
Con EU 2008 in Amsterdam was when I first understood some of the basic concepts
of how things are supposed to work around here, what kind of contributions
should be rewarded.
Only much later did I come across books like Producing Open Source Software, did
I watch several keynotes on how things work over at Debian and friends, did I
read about C4 at ZeroMQ, did I see things like the "Poisonous People" video.
To cut a really long story short: I may be mistaken, but I think even with the
incubator community members may not even be aware of a lack of merit. Look at
the thread over here:
http://mail-archives.apache.org/mod_mbox/community-dev/201610.mbox/browser
isn't that already showing that some questions arise only way after incubation?
> If this is breaking down then its a problem within the PMC not with the process, which has served us well for many years across many projects and should, IMHO, serve us well for many more. Rather than starting to look for a solution to a problem purebred by others perhaps we should look at why they have this perception.
Just for the record: I don't think we have a process problem per se here. We
might have an education problem: In terms of what (even if it's little) we
expect from projects, in terms of what people should do when they see those
expectations not being met, in terms of what is being done within the ASF to
keep things in line (or phrased more bluntly: If everything goes wrong, what can
you expect the board to do to your project? How did we educate projects in the
past?)
> Here's my thoughts...
>
> Open source, in general, has changed. Its gone from mostly individual hackers from small collaborating companies "scratching their own itch" to mostly big business and will funded startups paying individuals who sometimes don't care on a personal level. This has resulted in the emergence of a different flavor of open source. One in which money and metrics count more than community and code. I'm the money and metrics model success means market disruption rather than collaboration on code.
This matches with some of what I see as well.
> I maintain that the Apache Way is still a highly valuable and repeatable process that when applied correctly brings the highest chance of success (where success is valuable open source code). It is a process that is designed to ensure that those who care on a personal level have as much influence as those who are motivated by external need. It is a process that leaves money and metrics at the door but recognizes community and code contributions quickly.
The "recognizes *community* and code contributions *quickly*" is something I
would like to see validated across communities. I'm pretty sure even Mahout is
guilty of having waited long to hand committer status out to people who contribute
on a non-Java-level.
> I'm not a fan of metrics. They are often misleading and allow any story to be told. I'm much more interested in people taking responsibility for the health of their community than taking the easy route and monitoring an arbitrary metric. Those people should be working within project PMCs to ensure all contributions (code or otherwise) are being recognized. They should be identifying new committees not a "number of commits" metric that ignores the individual who facilitates consensus and merit recognition on our mailing lists.
Just for the record: "number of commits" IMHO is way too short sighted.
Documentation, help on mailing lists, providing use cases in JIRA to issues all
count.
> If a PMC is devoid of such individuals then it is nothing more than a shared code base regardless of how many new committers are brought in. Those projects exist, but they should not exist in the ASF where we stand for "community before code".
>
> The current metric, reported quarterly, to a vendor neutral and member elected board is "last addition of a committer". This is good. When it goes a long time the board should ask "why". Sometimes its because a project is in maintenance mode (no problem with that) other times its because a PMC is not recognizing contributions and needs reminding.
This is a good start, and I've seen people ask why often in the past. I'm not
sure it captures the balance between busy projects with paid contributors that
are being added routinely and people contributing as a side project but on a
continuous basis. I have no idea how to capture that balance well though.
> Do we really need metrics? Perhaps we need more awareness in our communities about why building a personal profile in a project is good for both career and community. Then we can help people build those personal profiles by ensuring we recognizing all contributions that bring stability, independence and health to a project community.
+1
Isabel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Two small comments:
Ross Gardler wrote on 10/25/16 10:19 AM:
> First, I'm tired of hearing it too but let's not be fooled, most of
> the time it comes from people ill informed about how the ASF works.
>
> We use social controls within the projects and we have a fully
> independent board to handle escalations should a community member
> feel that their (or anothers) merit not be recognized.
>
> If this is breaking down then its a problem within the PMC not with
> the process, which has served us well for many years across many
> projects and should, IMHO, serve us well for many more. Rather than
> starting to look for a solution to a problem purebred by others
> perhaps we should look at why they have this perception.
Part of this issue is lack of easily consumable and definitive
information on how our governance models work. Yes, we have some public
documentation, but it's scattered, inconsistent, and much of it is not
very friendly to newcomers. There are a lot of bits of tribal knowledge
that some of us understand intuitively, but that aren't actually written
clearly enough to communicate them broadly.
Obviously, some people won't read this stuff anyway. But at least
having a better set of URLs that we can send out to point to our
corporate policies, user stories, or even metrics would go a long way in
making it easier for us to respond to newcomers with a consistent set of
stable information.
...snip...
> Isabel Drost-Fromm wrote on 10/25/16 3:50 AM:
...snip...
>> [5]
>>
https://lists.apache.org/thread.html/76610c48321397e7af8e2e433ac73e6e1da4aa1a80b1fac67e7ed8c2@%3Cboard.apache.org%3E
Please note that this [5] link is to a privately archived list - so many
folks here won't be able to see anything there in Pony Mail, even if you
login.
- Shane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Jacques Le Roux <ja...@les7arts.com>.
I do love this answer
Thanks Ross!
Jacques
Le 25/10/2016 16:19, Ross Gardler a crit :
> First, I'm tired of hearing it too but let's not be fooled, most of the time it comes from people ill informed about how the ASF works.
>
> We use social controls within the projects and we have a fully independent board to handle escalations should a community member feel that their (or anothers) merit not be recognized.
>
> If this is breaking down then its a problem within the PMC not with the process, which has served us well for many years across many projects and should, IMHO, serve us well for many more. Rather than starting to look for a solution to a problem purebred by others perhaps we should look at why they have this perception.
>
> Here's my thoughts...
>
> Open source, in general, has changed. Its gone from mostly individual hackers from small collaborating companies "scratching their own itch" to mostly big business and will funded startups paying individuals who sometimes don't care on a personal level. This has resulted in the emergence of a different flavor of open source. One in which money and metrics count more than community and code. I'm the money and metrics model success means market disruption rather than collaboration on code.
>
> I maintain that the Apache Way is still a highly valuable and repeatable process that when applied correctly brings the highest chance of success (where success is valuable open source code). It is a process that is designed to ensure that those who care on a personal level have as much influence as those who are motivated by external need. It is a process that leaves money and metrics at the door but recognizes community and code contributions quickly.
>
> I'm not a fan of metrics. They are often misleading and allow any story to be told. I'm much more interested in people taking responsibility for the health of their community than taking the easy route and monitoring an arbitrary metric. Those people should be working within project PMCs to ensure all contributions (code or otherwise) are being recognized. They should be identifying new committees not a "number of commits" metric that ignores the individual who facilitates consensus and merit recognition on our mailing lists.
>
> If a PMC is devoid of such individuals then it is nothing more than a shared code base regardless of how many new committers are brought in. Those projects exist, but they should not exist in the ASF where we stand for "community before code".
>
> The current metric, reported quarterly, to a vendor neutral and member elected board is "last addition of a committer". This is good. When it goes a long time the board should ask "why". Sometimes its because a project is in maintenance mode (no problem with that) other times its because a PMC is not recognizing contributions and needs reminding.
>
> Do we really need metrics? Perhaps we need more awareness in our communities about why building a personal profile in a project is good for both career and community. Then we can help people build those personal profiles by ensuring we recognizing all contributions that bring stability, independence and health to a project community.
>
> Ross
>
>
>
> ---
> Twitter: @rgardler
>
> ________________________________
> From: Isabel Drost-Fromm <is...@apache.org>
> Sent: Tuesday, October 25, 2016 12:50:21 AM
> To: dev@community.apache.org
> Subject: On wearing multiple hats
>
> 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.
>
>
> 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.
>
> 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?
>
> - 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?
>
>
> Maybe from there we can come up with stories and metrics that hold (or should
> hold) for all of our projects.
>
>
>
> 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?
>
> Anyone interested in this? Anyone interested in helping get sensible numbers up
> - my JIRA magic is seriously lacking...
>
>
> Isabel
>
>
> [1]
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-spark-developers-list.1001551.n3.nabble.com%2FSpark-Improvement-Proposals-tt19268.html%23none&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327433262&sdata=a9bodenqUL8m0ystlfamKzvxmuZ2I5RR5Fa%2BdDNk4iE%3D&reserved=0
>
> [2]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DF0DpP25QCfQ%26list%3DPL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ%26index%3D13&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327433262&sdata=yhdmcZS7M5V0zqeGXK1KGVJ79yEXt45Am%2FyflJtUpYQ%3D&reserved=0
>
> [3]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D26T-UKAs1Fk%26list%3DPL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ%26index%3D11&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327443270&sdata=pJ%2BGbD2KGUIcJbLNWxwDKrSATUge6jyynJpoPigphBw%3D&reserved=0
>
> [4] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.flickr.com%2Fphotos%2Fcarlossg%2F4081471635&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327443270&sdata=cFzyp4oMgMz3apwWB73AYQDxEcWZIPzxxNH2y1GAbkc%3D&reserved=0
>
> [5]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F76610c48321397e7af8e2e433ac73e6e1da4aa1a80b1fac67e7ed8c2%40%253Cboard.apache.org%253E&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327443270&sdata=y1BBiuIHN6YcSsdE5zI1ZFkIIFwhhkhEcaLpdWnB1VM%3D&reserved=0
>
> --
> 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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Ross Gardler <Ro...@microsoft.com>.
First, I'm tired of hearing it too but let's not be fooled, most of the time it comes from people ill informed about how the ASF works.
We use social controls within the projects and we have a fully independent board to handle escalations should a community member feel that their (or anothers) merit not be recognized.
If this is breaking down then its a problem within the PMC not with the process, which has served us well for many years across many projects and should, IMHO, serve us well for many more. Rather than starting to look for a solution to a problem purebred by others perhaps we should look at why they have this perception.
Here's my thoughts...
Open source, in general, has changed. Its gone from mostly individual hackers from small collaborating companies "scratching their own itch" to mostly big business and will funded startups paying individuals who sometimes don't care on a personal level. This has resulted in the emergence of a different flavor of open source. One in which money and metrics count more than community and code. I'm the money and metrics model success means market disruption rather than collaboration on code.
I maintain that the Apache Way is still a highly valuable and repeatable process that when applied correctly brings the highest chance of success (where success is valuable open source code). It is a process that is designed to ensure that those who care on a personal level have as much influence as those who are motivated by external need. It is a process that leaves money and metrics at the door but recognizes community and code contributions quickly.
I'm not a fan of metrics. They are often misleading and allow any story to be told. I'm much more interested in people taking responsibility for the health of their community than taking the easy route and monitoring an arbitrary metric. Those people should be working within project PMCs to ensure all contributions (code or otherwise) are being recognized. They should be identifying new committees not a "number of commits" metric that ignores the individual who facilitates consensus and merit recognition on our mailing lists.
If a PMC is devoid of such individuals then it is nothing more than a shared code base regardless of how many new committers are brought in. Those projects exist, but they should not exist in the ASF where we stand for "community before code".
The current metric, reported quarterly, to a vendor neutral and member elected board is "last addition of a committer". This is good. When it goes a long time the board should ask "why". Sometimes its because a project is in maintenance mode (no problem with that) other times its because a PMC is not recognizing contributions and needs reminding.
Do we really need metrics? Perhaps we need more awareness in our communities about why building a personal profile in a project is good for both career and community. Then we can help people build those personal profiles by ensuring we recognizing all contributions that bring stability, independence and health to a project community.
Ross
---
Twitter: @rgardler
________________________________
From: Isabel Drost-Fromm <is...@apache.org>
Sent: Tuesday, October 25, 2016 12:50:21 AM
To: dev@community.apache.org
Subject: On wearing multiple hats
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.
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.
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?
- 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?
Maybe from there we can come up with stories and metrics that hold (or should
hold) for all of our projects.
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?
Anyone interested in this? Anyone interested in helping get sensible numbers up
- my JIRA magic is seriously lacking...
Isabel
[1]
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-spark-developers-list.1001551.n3.nabble.com%2FSpark-Improvement-Proposals-tt19268.html%23none&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327433262&sdata=a9bodenqUL8m0ystlfamKzvxmuZ2I5RR5Fa%2BdDNk4iE%3D&reserved=0
[2]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DF0DpP25QCfQ%26list%3DPL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ%26index%3D13&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327433262&sdata=yhdmcZS7M5V0zqeGXK1KGVJ79yEXt45Am%2FyflJtUpYQ%3D&reserved=0
[3]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D26T-UKAs1Fk%26list%3DPL055Epbe6d5YSf1gQ-KL68xI9QsE70oIZ%26index%3D11&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327443270&sdata=pJ%2BGbD2KGUIcJbLNWxwDKrSATUge6jyynJpoPigphBw%3D&reserved=0
[4] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.flickr.com%2Fphotos%2Fcarlossg%2F4081471635&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327443270&sdata=cFzyp4oMgMz3apwWB73AYQDxEcWZIPzxxNH2y1GAbkc%3D&reserved=0
[5]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F76610c48321397e7af8e2e433ac73e6e1da4aa1a80b1fac67e7ed8c2%40%253Cboard.apache.org%253E&data=02%7C01%7CRoss.Gardler%40microsoft.com%7C6e0e90b7e439498ae57108d3fcab9729%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636129786327443270&sdata=y1BBiuIHN6YcSsdE5zI1ZFkIIFwhhkhEcaLpdWnB1VM%3D&reserved=0
--
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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Isabel Drost <is...@apache.org>.
On Tue, Oct 25, 2016 at 10:58:17AM -0400, Sam Ruby wrote:
> On Tue, Oct 25, 2016 at 3:50 AM, Isabel Drost-Fromm <is...@apache.org> wrote:
> > - 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.
Sorry - that last question was mis-leadingly phrased. What I meant to ask was,
what kind of value are projects getting from becoming an ASF project? (I got
(and answered from my perspective) that question several times in the past, but
would love to hear broader input).
> 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.
Would it make sense to have public (anonymised) documentation of past examples
for that and for what was done to fix those problems?
As an addition to the above: If there really is a shift in how open source is
being done today, I would bet other projects are facing similar issues and would
love to hear our perspective.
Isabel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: On wearing multiple hats
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Oct 25, 2016 at 3:50 AM, Isabel Drost-Fromm <is...@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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org