Growing the Harmony community

[Tim Ellison <t....@gmail.com>]

For Harmony to be successful we need to grow the active development
community from where we are now.  Thinking about how we grow, I see a
couple of goals:

- expand the number of people contributing to development

After the initial and necessary work to set the legal framework for
contribution, we now need to make it clear how people can get involved
and contribute to Harmony.  The paperwork can look daunting, so a
summary on the website/wiki would be good.

We have got code contributions in the VM and class library space.  The
committers should spend time describing how that existing code works as
well as continuing active development.  Some of that description may be
best done here on the list, and some of that may be more static on the
website.

We should describe a set of near-term goals, to show people where we are
going and where they can help.  Putting some issues into JIRA as we work
on them will help, but also an indication of simple fixes/major tasks on
the wiki or website would give everyone a sense of project direction.

Archie's suggestion of publishing snapshots is great.  If we publish
regular snapshots with a summary of advances and capabilitites then we
will encourage developers (and maybe reckless users<g>) to give it a spin.

 - expand the existing committers responsibility

The Harmony website is looking unloved.  IMHO all committers should feel
responsible for keeping it up to date and relevant.

Looking at the list of incubator projects [1], I see there are eight
mentors for Harmony, and there are 13 committers for Harmony on Jim's
committer list [2].  I realize that not all mentors and committers are
going to be equally active on the project, but shouldn't the active
committers be members of the PPMC?

[1] http://incubator.apache.org/projects
[2] http://people.apache.org/~jim/committers.html


 - don't get me wrong

I don't mean this note to sound negative; far from it, I want to share
some of the enthusiasm and excitement for the project as widely as
possible.  Consider it a call to arms for everyone, and especially the
existing committers (by which of course I include myself).

I promise to put aside time beyond code development to address some of
the issues above, update the website and document some of the project
successes to date (will have to understand Anakia first <g>) -- will you
join me?

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Re: Growing the Harmony community

[Geir Magnusson Jr <ge...@pobox.com>]

Tim Ellison wrote:
> For Harmony to be successful we need to grow the active development
> community from where we are now.  Thinking about how we grow, I see a
> couple of goals:
> 
> - expand the number of people contributing to development
> 

Yes, that would be the primary goal indeed!

> After the initial and necessary work to set the legal framework for
> contribution, we now need to make it clear how people can get involved
> and contribute to Harmony.  The paperwork can look daunting, so a
> summary on the website/wiki would be good.

Please, not the wiki.  Website.  That's where official information is.

> 
> We have got code contributions in the VM and class library space.  The
> committers should spend time describing how that existing code works as
> well as continuing active development.  Some of that description may be
> best done here on the list, and some of that may be more static on the
> website.

What I want to do here is have pages on each "component" (in the top 
level sense) on the website.  Right now, we have "classlib" and that 
should have a space.  Archie seems interested in bringing JCHEVM up out 
of sandbox, so that gets one...

> 
> We should describe a set of near-term goals, to show people where we are
> going and where they can help.  Putting some issues into JIRA as we work
> on them will help, but also an indication of simple fixes/major tasks on
> the wiki or website would give everyone a sense of project direction.

Yah - JIRA is good for this, becuase it's where you'd put them anyway, 
and there are some management tools for JIRA that let us keep track of 
them.  Wiki's tend to get stale I think - in this case, it would be a 
double-update needed.

> 
> Archie's suggestion of publishing snapshots is great.  If we publish
> regular snapshots with a summary of advances and capabilitites then we
> will encourage developers (and maybe reckless users<g>) to give it a spin.

Projects tend to do this nightly, so we should work towards that.  I 
realize we aren't there yet, but it should be the goal.


> 
>  - expand the existing committers responsibility
> 
> The Harmony website is looking unloved.  IMHO all committers should feel
> responsible for keeping it up to date and relevant.

All are.

> 
> Looking at the list of incubator projects [1], I see there are eight
> mentors for Harmony, and there are 13 committers for Harmony on Jim's
> committer list [2].  I realize that not all mentors and committers are
> going to be equally active on the project, but shouldn't the active
> committers be members of the PPMC?
> 
> [1] http://incubator.apache.org/projects
> [2] http://people.apache.org/~jim/committers.html

All active committers will be, yes.

geir

Re: Growing the Harmony community

[Dalibor Topic <ro...@kaffe.org>]

On Mon, Jan 16, 2006 at 12:29:23PM +0100, Mark Wielaard wrote:
> Hi Tim,
> 
> On Fri, 2006-01-13 at 10:38 +0000, Tim Ellison wrote:
> > For Harmony to be successful we need to grow the active development
> > community from where we are now.
> 
> > We should describe a set of near-term goals, to show people where we are
> > going and where they can help.
> 
> I think it would be great if you could better explain where in the
> ecosystem you fit in. There is a pretty nice document with a roadmap for
> where we as free software community are going and how we go about it
> http://developer.classpath.org/support/ how can harmony enhance that?
> 

I'd say by being a friendy place for corporations that want to try out 
becoming a part of the whole free runtimes thing, without having to fear 
to lose too much control, and being assisted by gentle, friendly developers
on their way towards fully embracing the open source development model. The 
ASF has a bit of experience in that area, having led Derby, Tomcat, and 
other similar contributions into the open.

There are numerous proprietary runtime manufacturers, and some of them may
be sooner or later compelled to try licensing parts of their proprietary
technology under open source licenses. Not all of them could possibly be 
able to merge their technology in a resonable time frame with the other 
existing projects in this area, so Apache Harmony can provide an outlet
into open, where no such merging effort is necessary.

Otoh, I do not see Apache Harmony adopting GNU Classpath in the near 
future, since that would put heavy merging pressure on potential corporate 
contributions with the already existig code in GNU Classpath, and so 
potentially serve as a deterrent. Let them come out in the open first,
it's a big step already as it is. ;)

I don't see that as a problem, though. The current strategy is obviously 
working very well, and in the long run, another complete free software J2SE 
stack is a nice prospect.

> > I don't mean this note to sound negative; far from it, I want to share
> > some of the enthusiasm and excitement for the project as widely as
> > possible.  Consider it a call to arms for everyone, and especially the
> > existing committers (by which of course I include myself).
> 
> To be honest a lot of my initial enthusiasm has gone away when I saw
> that as harmony founder my suggestions seem to be ignored. I do know how
> to grow a community and I would love harmony to be part of the growth.
> But it seems a lot of the suggestions we made have just been ignored.
> let me list them again so you can see what makes sense:

I believe the way Apache Harmony works is slightly different from other 
communities I've been involved with, for example. I don't see it morphing
into something else, and again, I don't see it as problem either.

It's a 'horses for courses' sort of thing, in my opinion. I don't think
that using the bandwidth of this mailinglist to debate how to grow 
Apache Harmony towards or within GNU Classpath is productive at all. 
We've had that discussion in the past a few times, and it wasn't very 
fruitful.

I think Apache Harmony has already found its own niche, the one I 
mentioned above. It does not need GNU Classpath, as it now has its own
class library to work on, and GNU Classpath seems to be progressing 
really well without swapping code with Apache Harmony, too. So the whole
pressing notion of having to find a modus operandi for collaboration
on source code between the two projects seems to be unwarranted to me.

With my Kaffe maintainer hat on, I'd see Apache Harmony as another 
potentially interesting runtime in the future, like Parrot. With my 
Apache Harmony founder hat on, I'd see GNU Classpath based runtimes as
potentially interesting projects that share the same goals, but chose a
different way to go about it, and target a different audience.

cheers,
dalibor topic

> - Try to enhance and work together with the existing projects whenever
> possible: http://www.gnu.org/software/classpath/stories/ there are
> active communities out there with a lot of diversity and knowledge.
> - To make sharing possible make sure you use a distribution policy that
> alligns with these projects. In particular most existing projects are
> GPL-compatible, make sure your contributions are also so they can be
> easily integrated. Use an exception like GNU Classpath as necessary if
> you want to use the Apache license but also like to integrate for
> example.
> - For supporting lots of platform and architectures (see the stories
> above) take a look at the VM integration guide and help improve that. If
> you get patches in that will help all the 30+ projects listed above. It
> is a nice setup that works for a lot of different platforms and
> architectures, even for things like static compilers, .net integration,
> etc.
> - There is a strong feeling that we should try and work together on a
> set of standard libraries with all the projects. In the past various
> projects had their own standard libraries, now almost everybody
> cooperates on the GNU Classpath set. Please join that effort.
> - There is a similar thing for creating a test suite that will help all
> projects collaborate on quality management, Mauve. Improving that helps
> the whole community, while having separate project specific test suites
> are much harder to share.
> 
> A lot of the existing community and a lot of the Harmony founders
> (Dalibor, Tom, Jeroen, Geir, I and if he can make it Leo) will be at the
> GNU Classpath and friends meeting in Brussels next month. It would be
> cool if you could join that meeting because there are a lot of people
> there that would like to cooperate if you are serious about it. See
> http://www.gnu.org/software/classpath/events/fosdem06.html
> 
> Cheers,
> 
> Mark
> 
> -- 
> Escape the Java Trap with GNU Classpath!
> http://www.gnu.org/philosophy/java-trap.html
> 
> Join the community at http://planet.classpath.org/

Re: Growing the Harmony community

[Mark Wielaard <ma...@klomp.org>]

Hi Tim,

On Fri, 2006-01-13 at 10:38 +0000, Tim Ellison wrote:
> For Harmony to be successful we need to grow the active development
> community from where we are now.

> We should describe a set of near-term goals, to show people where we are
> going and where they can help.

I think it would be great if you could better explain where in the
ecosystem you fit in. There is a pretty nice document with a roadmap for
where we as free software community are going and how we go about it
http://developer.classpath.org/support/ how can harmony enhance that?

> I don't mean this note to sound negative; far from it, I want to share
> some of the enthusiasm and excitement for the project as widely as
> possible.  Consider it a call to arms for everyone, and especially the
> existing committers (by which of course I include myself).

To be honest a lot of my initial enthusiasm has gone away when I saw
that as harmony founder my suggestions seem to be ignored. I do know how
to grow a community and I would love harmony to be part of the growth.
But it seems a lot of the suggestions we made have just been ignored.
let me list them again so you can see what makes sense:
- Try to enhance and work together with the existing projects whenever
possible: http://www.gnu.org/software/classpath/stories/ there are
active communities out there with a lot of diversity and knowledge.
- To make sharing possible make sure you use a distribution policy that
alligns with these projects. In particular most existing projects are
GPL-compatible, make sure your contributions are also so they can be
easily integrated. Use an exception like GNU Classpath as necessary if
you want to use the Apache license but also like to integrate for
example.
- For supporting lots of platform and architectures (see the stories
above) take a look at the VM integration guide and help improve that. If
you get patches in that will help all the 30+ projects listed above. It
is a nice setup that works for a lot of different platforms and
architectures, even for things like static compilers, .net integration,
etc.
- There is a strong feeling that we should try and work together on a
set of standard libraries with all the projects. In the past various
projects had their own standard libraries, now almost everybody
cooperates on the GNU Classpath set. Please join that effort.
- There is a similar thing for creating a test suite that will help all
projects collaborate on quality management, Mauve. Improving that helps
the whole community, while having separate project specific test suites
are much harder to share.

A lot of the existing community and a lot of the Harmony founders
(Dalibor, Tom, Jeroen, Geir, I and if he can make it Leo) will be at the
GNU Classpath and friends meeting in Brussels next month. It would be
cool if you could join that meeting because there are a lot of people
there that would like to cooperate if you are serious about it. See
http://www.gnu.org/software/classpath/events/fosdem06.html

Cheers,

Mark

-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/

Re: Growing the Harmony community

[Leo Simons <ma...@leosimons.com>]

Nice email, tim! I'm just responding to some small bits.

On Fri, Jan 13, 2006 at 10:38:36AM +0000, Tim Ellison wrote:
> We should describe a set of near-term goals, to show people where we are
> going and where they can help.

Geir, do you have that presentation from AC somewhere which had the list of
short- medium- long-term goals in it in a shareable format?

> Looking at the list of incubator projects [1], I see there are eight
> mentors for Harmony, and there are 13 committers for Harmony on Jim's
> committer list [2].  I realize that not all mentors and committers are
> going to be equally active on the project, but shouldn't the active
> committers be members of the PPMC?

Interesting question, and a good one to ask.

There has been some discussion about this on the PPMC list. I forgot what
the end of the story was. Basically at some point the PPMC is going to vote
on adding some of the committers to itself. The ASF is currently (and
always :-)) in a process of (re)evaluating its internal structures, policies,
etc (if you read general@incubator you get some feeling for it). Different
projects do things a little differently.

For example, there's projects where the rule is roughly "committers =~ PMC"
(like HTTPD) and there's also projects where its "committers >> PMC" (like
jakarta which has 100s of committers and about a 100 people on its PMC)
and then there's various options in the middle and other variations along
different axes (gump doesn't really have a solidified "committer" role).

With harmony we're again doing a few more things a little more differently,
eg we have "partitioned commit access" based on "previous exposure" and
a contribution framework which is somewhat different from the rest of the
ASF its processes, and this trickles down into figuring out how to do these
kinds of things, too.

For example, I haven't filed the relevant harmony contributor forms yet, so
while I'm on the PPMC (and if I don't have karma for the entire SVN tree I
can easily add myself since I do sysadmin work around the ASF), I really
should not be touching the "protected" codebases just yet.

Some projects brought into incubation bring with them a whole bunch of
new people to the ASF who are immediately then committers and PPMC members
(derby is one example). With harmony we're doing things a little
differently. A little more slowly, little more carefully. There's really no
set policy on what the differences are, its just the PPMC sort-of winging it
based on experience and mutual agreement and stuff like that.

In any case, rest assured there's almost no traffic on harmony its PPMC
mailing list and that's firmly going to stay that way no matter who is on
it :-)

cheers!

LSD