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
