future content of OpenJFX

[Kevin Rushforth]

I think this is a great way to frame the discussion.

To add to the part about developers sometimes being willing to 
contribute part of the cost for feature X, I would say that in some 
(many?) cases, those developers might even think that they are doing the 
entire job by implementing feature X. It's been my experience, that 
contributors to an open source project often don't realize that the 
"total cost" of a new feature includes making sure that the design and 
interfaces are solid, that it is well documented, that it fits in with 
the existing features, that the interactions with other components in 
the system have been fully explored and addressed, that the 
implementation is both testable and has tests (preferably automated) 
that verify correct operation, fixing bugs for a period of time (no 
significantly large feature is completely bug free), etc. Additionally, 
there is the time and effort needed to review the work for correctness, 
security, maintainability, etc.

Not to mention that the larger and more intrusive a feature is, the more 
carefully it will need to be reviewed by people who know the areas of 
code in question.

-- Kevin


Johan Vos wrote:
> In order to separate the "What" from the "How" (discussed in another
> thread), I would like to start a discussion about what people think should
> be considered for future JavaFX work.
>
> I'd like to start with what I think is an important note on the context.
> If I want feature X in JavaFX, I ask myself two questions:
> 1. Do I want to contribute time and do it (at least for a large part)
> myself?
> 2. Do I want to spend money on it?
>
> If that sounds too economic or commercial, I recommend reading the
> excellent blog entry by David Blevins about funding Java EE development
> (more than 4 years old and still very relevant):
> http://www.tomitribe.com/blog/2013/11/feed-the-fish/
>
> Actually, this is a model we've been using at Gluon for a number of
> customers. When people ask us about a specific feature, we ask if they are
> willing to pay us for the development, AND if they are ok with us donating
> it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX,
> JavaFXports, Gluon Charm Down, Gluon Maps,...).
> As a consequence, the features we are working on are all relevant to (at
> least a part of) the industry. Some companies doubt there is business value
> in JavaFX, we prove the opposite while making the Open Source community
> better.
>
> I think by now it should be clear to all that there is no free lunch
> (anymore). If your business depends on a feature being added to JavaFX, how
> much (time/money) are you willing to contribute? If the answer is
> "nothing", you can still hope that others want to do it, and in many cases
> that will eventually happen -- but you don't control the timeline.
>
> This principle is a bit a simplification though. In many practical cases,
> people want to have feature X and are willing to contribute "something"
> (e.g. they want to work on it in spare-time, or fund 20% of a developer)
> but not enough to do everything.
> I think in this case it's a matter of gathering enough interest in this
> community. Once enough developers are interested in that same feature, and
> agree to spend resources on it, the burden can be shared. Having a sandbox
> repositories with forks will make this easier.
>
> Areas that I personally want to see on the roadmap:
> * more alignment with mobile
> * a clean and lean low-level rendering pipeline API that would allow easier
> plugability with upcoming low-level rendering systems
> * extensions for Chart API
>
> - Johan
>