incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Incubation state transitions and stuck projects (Was: February report review)
Date Tue, 17 Jul 2012 15:07:50 GMT
Here are some thoughts about this based on my particular experiences.
So I won't preface each particular observation with 'In my

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

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:

View raw message