Hi, > 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? Thanks, Justin 1. https://en.wikipedia.org/wiki/Bus_factor
