[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    How to Grow Contributions (was The Next Great Thing: An Application Framework)
From:       richard.bair () oracle ! com (Richard Bair)
Date:       2012-02-21 19:17:54
Message-ID: D07F29B7-FE97-4D0F-B48A-14B4FDF3D9DB () oracle ! com
[Download RAW message or body]

Hi Daniel,

> Just for your info one of the challenges I have in contributing to the JFX code \
> base is the whole version management side of things. Since I am working on \
> deliverable projects I need my local dev environment and runtime to be the latest \
> stable release. With JFX being only partially open sourced, there's the whole need \
> for getting hold of these dependent jars. I'm scared to download and install any \
> new versions of JFX (beta or otherwise) as I can't risk hurting my actual dev \
> environment and I'm not entirely confident I know what the 'install' actually does \
> and/or how and when the auto-updater will come into play.

As long as you don't test applets, this isn't too difficult. Well, at least on mac. \
Is there a src distribution yet for windows? I know there is/was a bug for it that \
is/was being fixed. But this is valuable feedback, I'm very interested and concerned \
about growing the community involvement so it is nice to know what kinds of \
roadblocks are in the way.

> The other challenge, and this will be the same for everyone, forever, is time. \
> There's never enough. Currently I am splitting what free time I have between \
> helping out on the forum, trying to evolve my JFX Flow project, contributing to \
> this dev forum and adding to my blog to show people ways to build 'real' \
> applications. Occasionally I also like to go outside and sometimes even socialise \
> ;)  I'm wondering what your thoughts (and the thoughts of people in general) are on \
> the best use of community time? This kind of leads back to that community space I \
> was rambling about a few emails ago - somewhere (with more tools than just this \
> mailing list) where we can focus community efforts, coordinate and collaborate, and \
> really make use of the big community resource pool instead of us all throwing in \
> bits and pieces from the side. i.e. a revamped java.net or a total replacement of \
> it with the same end goals just executed properly. 

And really, the community involvement on the forums as been absolutely fantastic. The \
traffic level has really picked up and there's no way I'm able to even read it all \
let alone answer with code anymore. I think everybody will have different ways in \
which they contribute.

I'm working with Brian and others to get all the tools in place. Well, a bunch of \
them anyway. We're planning on JIRA obviously for bugs, Confluence for a wiki, \
Crucible for code review. We will probably continue using Hudson, but setup an \
external hudson instance which continually builds and tests the open source bits \
(we'll keep the internal one even after the platform has been full open sourced to \
build and test with the proprietary stuff like fonts which, although they will have \
an open source equivalent, we'll continue to use the proprietary one for the version \
of JavaFX we ship until we can fully retire it). We've got a find-bugs job on hudson \
in addition to the tests, so there's a bunch of stuff there as well.

Honestly I'd probably use something like github as a place to host experimental code \
and such. Creating projects in OpenJDK involves a certain amount of overhead and, \
well, google code or github are pretty great place for low-overhead project hosting.

> In all brutal, practical honesty, the one area that Oracle is now semi-obliged (for \
> their own self-interest if nothing else) to invest money and resources is in \
> maintaining the core JFX platform/plumbing. Fixing bugs and sorting out those low \
> level features that the platform requires. From a pragmatic perspective, it seems \
> like the area where the community is better to try and add benefit is in these \
> middle-tier frameworks, such as application frameworks, validation toolkits, etc. 

One problem I've seen quite a bit in the past with open source projects such as this \
is that the thing most people want to contribute to are new features. Which is great, \
but it can be frustrating because new features, by necessity, take time to bake and \
are bottle necked on API approvals and such. Also, every new feature carries with it \
both maintenance and testing costs (and documentation and localization and so on). So \
as Oracle, even for new platform/plumbing features, we can't take them unless our bug \
backlog is in reasonable condition.

Really what I'm hoping for with JavaFX is that there isn't an Oracle vs. Community or \
us vs. them concept in any of it. What I would most love is to have people who don't \
work for Oracle be full members of the team -- even participate in Scrum conference \
calls and writing tests and fixing bugs or build system stuff --- everything.

Now of course, most folks have a day job and so this is obviously not practical for \
many people. But I do hope that there will be enough folks who's day jobs depend on \
it, that being full participants is something their employer encourages to their own \
advantage.

> What's the general thinking here, how do we get maximum benefit from our resource \
> pool that includes paid, full time Oracle resources working as a managed team and \
> coordinated by an organised management structure, as well as a floating pool of \
> part-time, add-hoc, random developers doing it for kicks or glory, all flying solo \
> and all with their own ways of doing things and views of the way-it-should-be?

That is the question! It seems to me that the following are musts:
	- Low barrier to entry
		- Project process must be clear and transparent
		- Release cycle timeline must be clear and transparent
		- Build must be easy
		- IDE support must be built-in to our build files (just use your IDE for \
                everything)
		- Writing tests must be clear
		- Running regression tests must be easy
		- Architecture documents must be abundant and clear
	- Equal Opportunity
		- Planning process must be clear and transparent
		- Clear path for becoming project committers
	- Involvement
		- Work with JUGs to do things such as OpenJDK "Fix a Warning Day"

Ah, there were a few more but they just slipped my mind. Although some hardcore \
hackers can devote time to contribute, overcoming these significant numbers of \
hurdles, most folks won't. And until we make the process so easy that somebody who \
has a bug, and needs it fixed, can contribute a fix that passes the tests and can be \
integrated quickly -- we won't be at the point where we're truly offering the benefit \
of an open source project.

Cheers
Richard


[prev in list] [next in list] [prev in thread] [next in thread]