flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: [FlexJS] PAYG definitions and guidance, Please participate
Date Tue, 04 Jul 2017 00:03:49 GMT

> You could be right that folks are just too used to the old Flex way of
> thinking.  If you've never hit the performance and size issues I've seen
> then maybe you can't understand the motivation behind it, but that might
> mean the active committers are self-selected.

I’ve worked on many large enterprise Flex systems and while we run into performance issues
from time to time but they were generally solvable. Sometimes in the code itself or at worse
by monkey patching the SDK. Not everyone experience is going to be the same.

> it could be that the big enterprises that have been
> burned by old Flex's size and performance are no longer active Flex
> customers.

There are a large number of reasons for that i.e a lot of big enterprises like paid support
from a supplier, some are still reluctant to using open source (although that is changing)
and finding Flex developers these days is hard and/or expensive, other frameworks may have
more traction, popularity, hype or larger communities behind them.

> Documentation is always a good thing, but as I've said several times, this
> is bleeding-edge development.

Having worked on a number of bleeding-edge systems IMO I’m not sure it really qualifies
for the term. There are other frameworks in this space, other cross compilers etc etc and
there’s nothing really that cutting edge about it. It’s true that it’s currently mostly
untested in production so in that way it may qualify.

>  I'm just not sure we are ready to start paving roads and putting up street signs.

If we want to attract other developers / committers it may be a good idea to at least leave
some notes on the direction travelled and how to get there.

>   Adobe can pull me off at any time.

All the more reason IMO to have some documentation and censuses around concepts like PAYG.
Bus factor is a concern here. [1]

>  My managers would much rather that I help one or two customers migrate their code than
> write documents so 100 folks can migrate on their own because we still
> have enough bugs and missing features that the 100 would have little
> chance of being successful

Those's 100 people would get help from the mailing list and would hopefully become committers
themselves. I think you may be thinking that Flex needs more full time people sponsored by
a corporation working on it. That would be nice but also don’t discount part time committers
working on it as well as there’s room for both.

>  And having a successful customer improves the chances that Adobe will continue to pay
me to work on FlexJS.

What do you (or Adobe) define as successful here? We're currently working on an application
what does it need to do to help that?


1. https://en.wikipedia.org/wiki/Bus_factor
View raw message