incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Incubation state transitions and stuck projects (Was: February report review)
Date Tue, 17 Jul 2012 19:17:08 GMT
On 17 July 2012 11:44, Benson Margulies <> wrote:
> is an example that comdev might want to propagate?

I think this is a really interesting experiment and look forward to
seeing the outcomes. In many ways it simply formalises what a healthy
community should be doing anyway. It might be that making this
explicit in the way Maven is seeking will be beneficial.

Yesterday, here at OSCON, I participated in an Outercurve Foundation
session looking at this problem within their own projects. This
included representatives from a wide range of open source projects and
foundations. There were some interesting ideas. One, in particular,
caught my eye - Ubuntu have a gamified the developer engagement
process with a project called Ubuntu Accomplishments.

Personally I'm conflicted by this. I don't think I like the idea of
"trophies" as this brings competition into the community. However, the
process of creating the trophies led the Ubuntu team to create task
oriented documentation which looked pretty useful. In addition, their
automated code for detecting and awarding accomplishments could be
used to trigger a human response rather than a machine awarded trophy.
For example, clearly indicating that a bug report is the contributors
"first bug report" could prompt a quick personal email of the form
"thanks for taking the time... our project thrives because of people
like you... we'll review soon... if you want to follow up please mail



> On Tue, Jul 17, 2012 at 11:07 AM, Benson Margulies
> <> wrote:
>> Here are some thoughts about this based on my particular experiences.
>> So I won't preface each particular observation with 'In my
>> experience.'
>> There is a narrative around the Foundation about 'Diversity'. The
>> narrative goes like this: once upon a time, one (or more) projects
>> were predominantly staffed by volunteers supported by a single
>> employer. The story goes on to describe two bad outcomes that resulted
>> from this. In the first bad outcome, the employer's priorities
>> changed, all the volunteers wandered away, and the project withered.
>> In the second bad outcome, the volunteers with one employer exerted
>> undue influence over the technical direction of the project, freezing
>> out other contributors.
>> I've not seen the first problem with my own eyes, but I may have seen,
>> and swept up after, the remains of it. (Sort of like observing the
>> nebula after the supernova has exploded.) I've seen some conflicts
>> about the second. Not, however, in podlings, rather but in projects of
>> long-standing.
>> In the incubator, the stated requirement of Diversity is intended to
>> avoid graduating projects with these problems baked in. However,
>> before a project can even get to the doorstep of an actual diversity
>> problem in the sense described, it has to get over another hurdle. It
>> has to be large enough. If a podling has three people in it, the
>> problem is not 'the same employer pays all of them to contribute' --
>> it is 'there are only three people'!
>> Here, then, is the big 'community development' challenge. A small
>> group of people with a good idea (and perhaps) some code shows up,
>> collects mentors, and sets up shop. They learn the ropes, write more
>> code, make releases. They make some sort of web site. And they wait,
>> metaphorically, for the phone to ring.
>> There are, I assert, two possible explanations for this situation. One
>> is that, sadly, no one cares at all. No one uses the code, and so of
>> course no one shows up to contribute. The second possibility is that
>> there are users, but those users are not motivated to contribute.
>> Maybe the thing works so well that no one has an itch to scratch.
>> Maybe the users all work for organizations that don't, culturally, see
>> the value of contributions open source.
>> It would probably be good to try to understand which state any given
>> small podling is in when trying to help them.
>> Either way, this a marketing problem. The skills that write killer
>> code don't make killer web sites, let alone exercise other marketing
>> channels, let alone come up with ways of approaching large
>> organizations to suggest that they might want to encourage their
>> people to become contributors.
>> Some podlings have very compelling technologies, and succeed without
>> these skills. Some podlings have companies sponsoring their
>> contributors who also put marketing money and talent to work. We're
>> happy with this so long as they play nicely with trademarks.
>> Some podlings, however, don't have either of these advantages, and
>> need help. How can we help them?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ross Gardler (@rgardler)
Programme Leader (Open Development)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message