How to Grow Contributions (was The Next Great Thing: An Application Framework)

[Richard Bair]

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