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 18:44:36 GMT

is an example that comdev might want to propagate?

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:

View raw message