incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sally Khudairi>
Subject Re: How to grow podling communities
Date Tue, 27 Nov 2012 21:50:46 GMT
Thanks, Suresh. Hello Eric, Ross, and IPMC members.

We --ASF Marketing & Publicity-- are happy to work with any (P)PMC on a project's publicity
once the project has graduated from the Incubator.

We can issue a press release to announce the graduation --similar to [1], [2], and [3]. Once
you're a TLP, we can also help announce major project milestones in a press release [4] or
media alert [5] and [6], as well as advise on technical fact sheets [7] or "The ASF Asks:
Have You Met Apache [Projectname]?" -type of "birth announcements" [8] that provide further
technical details.

All official ASF announcements are published on an international news wire service, and also
posted on the ASF Foundation Blog and @TheASF Twitter feed.

Whilst projects are prohibited from issuing any formal announcements (over a newswire) whilst
undergoing incubation, we strongly encourage your contributors to blog about the project,
as well as publish updates on mailing lists, speak at conferences, hold meetups/barcamps/user
groups, and engage the community in other ways to build interest.

You are more than welcome to request blogging credentials from the ASF Infrastructure team
to post to --I recommend you consider asking that they establish
a project-specific sub-directory (such as ) so you have a dedicated
space for your project.

I also recommend you establish your own Twitter feed for the project and use the @TheASF,
#Apache, and #OpenSource tags (among others) where appropriate --lots of folks follow these
and help spread the word.

As for mailing lists, we have lots of technical journalists follow the
list as well as the public Incubator archives (at times I receive media queries about projects
I wasn't even aware were submitted for incubation!)

And I strongly suggest that we lean on friends, employers, users, and partners to help spread
the word. There's a company that issues a press announcement (mostly blogs) with every single
release made in the project that their products heavily rely on, with formal press releases
issued as "attaboys" to reinforce the ASF news. That project gains lots of visibility through
someone else's resources. Similar instances exist with outreach events, such as workshops,
trainings, and BoFs at conferences.

I *always* push for testimonials, use cases, and highly-visible implementations, both in our
press releases [9], [10] as well as project Websites [11] --as you can imagine, not only does
this give members of the press/analyst community the answer to "who uses you?", it also proves
to other possible users that the project is viable, credible, and reliable.

I hope this helps. Feel free to ping me or the team at if you need anything!



> From: Suresh Marru <>
>Cc: ASF Marketing & Publicity <> 
>Sent: Tuesday, 27 November 2012, 11:01
>Subject: Re: How to grow podling communities
>Apologies for the cross post, but I am including press since Eric has some constructive
observations here. 
>On Nov 27, 2012, at 1:44 AM, Eric Johnson <> wrote:
>> 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
>> 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 ©
>Eric, I sure do appreciate your ideas below, but don't forget incubator helps in making
legally complaint releases. Releases distinguish incubator from apache labs. And making frequent
releases and announcing them is one the best marketing technique which sells open source software.
In that sense,  of course the developers have great skill at this aspect of marketing :)
>> 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]
>> 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 []
>>>>> Sent: 27 November 2012 00:22
>>>>> To:
>>>>> 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
>>>>> 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 <>
>>>>> wrote:
>>>>>> ---------- Forwarded message ----------
>>>>>> From: *Benson Margulies*
>>>>>> Date: Monday, November 26, 2012
>>>>>> Subject: [VOTE] Retire Chukwa from incubation
>>>>>> To: "" <>
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message