I'm mostly just a lurker on this list, having thought about bringing a
project to Apache about 24 months ago[1], realizing we didn't quite have
the demand/community. Since then I've been lurking, wanting to see
when/whether it makes sense to attempt it again, reflecting on the state
of the project I'm working on.
From where I'm sitting, I think the incubator actually should do much
more here. Big picture - bunch of developers with some cool code come to
possible the foremost organization for open source projects. They start
incubating, and discover that part of their incubation process is to
market themselves to grow their community, and yet not much help arrives
to do that. On top of that, (a) the developers likely have weak
marketing skills, (b) don't have a budget for marketing & travel, (c)
aren't given any tips from others more experienced about what kinds of
resources they should scare up and which efforts they should focus on first.
I see the incubator process ought to play three roles:
a) teaching the Apache rules/community/approach
b) teaching optimal open source project hygiene (which includes items
listed below, such as quick turn-around on patch reviews, decent
website, tutorials, public mailing list discussion) - and actually
include "grading" on the quality of those items before graduation.
c) assistance and reporting on "marketing". What the heck does this mean?
I think the incubator currently has parts (a) & (b) down. Not so much
for (c)
For example:
What does it mean to do "press"? What would you include in a press
release? Where would you send it?
Apache has so many projects, shouldn't it do a monthly "highlight on
_____" report, calling out a top level project, and a project being
incubated? Automatic publicity! Expect incubating projects to
participate in one of those "highlight" reports before graduating....
What community events should a team focus on? What have teams done in
the past? What has worked? What hasn't worked? Do we know why it worked
or didn't work? Is this information being recorded anywhere?
Encourage teams to shamelessly request "reference" users that they can
post to their websites. Solicit "endorsements" from "neutral" third parties.
I've seen ideas tossed around on the incubator list, but generally
nothing concrete, so it feels to me like the projects are left drifting
in the wind, trying to figure this stuff out for themselves.
That's silly, because Apache has such huge name recognition in the
software world, it should be *easy* to draw attention to incubating
projects. Except that at the moment, the best way to follow what's
incubating seems to be hopping on this general list, where you will see
when projects submit proposals, see them voted on, and see when they get
in trouble. That's a lot of noise for a small amount of signal.
Capturing that signal publicly might help bring visibility to the
projects to follow.
For example, why doesn't the incubator have a twitter feed where the
status of incubating projects gets reported? Something that everyone can
follow, and discover when new projects are proposed, when projects are
at risk, and when they think about graduating?
Recognizing that everyone here has limited resources, I don't think
what's needed here is much more than a little bit of capturing existing
known data on a wiki page or three, perhaps a twitter feed, and some
small amount of nudging by mentors. At least as a start!
Eric.
[1] https://wiki.apache.org/incubator/gXMLProposal
On 11/26/12 8:03 PM, Alan Cabrera wrote:
I wonder if we can ask that incubation proposals include how they intend to get
the message out there. What channels are relevant for the project? I guess
what are their marketing plans.
Eventually, we'd have a collection of old incubation proposals that new
podlings could use to garner ideas on how to market and grow their community.
Regards,
Alan
On Nov 26, 2012, at 5:50 PM, Ross Gardler wrote:
Growing community is about "getting the message out there". There has to be
someone in the project who wants to do that. Some techniques are:
- press
- community events
- mentoring (that is mentoring of potential new committers)
- fast turnaround on patch reviews
- regular releases
- decent website
- tutorials
- screencasts
- public discussion (even with self while no community exists)
Developing code for one's own use is all well can good but it does not build
community and trying to build community doesn't, in the short term, write code.
It's a catch-22.
Personally I have no problem with a podling having low activity. A single
developer doing their thing in the incubator is not going to hurt anyone. What
I'm concerned about is a podling that is not doing any of the above community
development activities or, even worse, is ignoring potential contributors.
I don't think it is the responsibility of ComDev to do this, although one could
argue ComDev should be documenting these techniques in ways useful to mentors.
I don't think it is the job of mentors (or the IPMC) to do this either. It is
entirely the PPMC responsibility. In my opinion.
Ross
-----Original Message-----
From: Benson Margulies [mailto:bimargul...@gmail.com]
Sent: 27 November 2012 00:22
To: general@incubator.apache.org
Subject: Re: How to grow podling communities
Luciano,
My five cents is this: growing communities is really, really, hard, and I don't
know that anyone at Apache has a recipe. If anyone does, it might be the
comdev committee. I'm not sure that this PMC can take it on. We can barely
muster the minimal supervision that the board requires of us. If a PPMC
wants help, it might be good for it to make contact with comdev.
I hate to be such a pessimist, but I think that the incubator has to continue to
shrink until the number of podlings is in balance with the available
supervisory/mentor effort. At that point, maybe we can consider consider
more of an effort to support in addition to supervising.
Just, however, my opinion.
On Mon, Nov 26, 2012 at 3:58 PM, Luciano Resende <luckbr1...@gmail.com>
wrote:
---------- Forwarded message ----------
From: *Benson Margulies*
Date: Monday, November 26, 2012
Subject: [VOTE] Retire Chukwa from incubation
To: "general@incubator.apache.org" <general@incubator.apache.org>
For those voting -1, I'd like to see, on another thread, some
discussion about just how we handle podlings where there are
longstanding issues but no consensus on the PPMC. We've heading in the
same direction on Photark, and some consensus about how or when to
reach a respectful conclusion as a PMC that a project should be
retired even if the PPMC is not of the same opinion would be useful.
We cannot both say that we need projects to have active, supervising,
mentors and shepherds and then not, in some fashion, act on what they
tell us.
-----
I believe that the discussion we should have is how can we help
struggling podlings to grow their community in a sustentable way.
Recently, I have seen an increase in trying to push small communities
to retirement, but i'm yet to see active mentors engaging and helping
and motivating the podlings PPMC to find ways to grow.
Growing communities when a project is backed by corporations that
sponsor engineers to devote their full time volunteering at the
project is much easier compared to those other projects that are
developed by a small group of people, that devote their own free time
and are passionate by the Apache brand, and doing truly open source
following the Apache Way.
With my Community development hat, I would really like to see a wide
discussion on how the IPMC and COMDEV PMC could find ways to help
these struggling podlings succeed, instead of just giving ultimates
for seeking retirement. Things that come to mind are : make it easier
for new contributors to find tasks that they could work on, more
visibility for podlings in Apache sponsored conferences, etc
Thoughts ? Other possible ideas ?
Thanks
--
Luciano Resende
Sent from my iPhone
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
