[GitHub] [royale-asjs] greg-dove commented on issue #648: Tasks to Reach 1.0

[GitBox <gi...@apache.org>]

greg-dove commented on issue #648: Tasks to Reach 1.0
URL: https://github.com/apache/royale-asjs/issues/648#issuecomment-570708123
 
 
   Based on my experience working with React/React Native, I believe it will be much harder to attract React users than it will be to continue to focus on Flex migration users. I'm not saying that it won't be possible, just saying that I think it will be much harder. I think we have a better chance of achieving some growth from other JS frameworks if we build community first, and IMO it will still be easier to build that with Flex migration users (while we still have some).
   
   I do have substantial experience with marketing/business planning and implementation. But I left that behind some time ago and I freely admit I am not applying much more than general experience and instinct here. Without conducting research it's pretty hard for anyone to do much more I think. The only thing I have really considered in my thinking that is 'marketing-ish' is the notion of applying something like the 'adoption curve' model to the Flex migration process itself (not specifically for migrating Flex to Royale, but for migrating away from Flex by whatever means). I suspect that most of the proactive/forward-thinking 'customers' of the migration process have already done it. Those of you who have migrated your own apps to Royale are some of those people. Some may have chosen to retire their apps. Many others have chosen React, Angular, or other approaches. I'm hopeful that there are still quite a few left who have decided to re-assess Royale early this year before making the final selection and committing (I am aware of 2 in this position). But I can't imagine people leaving it much longer than that for anything that is important to their business. If you leave it so that completion of migration is after it no longer works in flash (2021) then it seems to me that it is either not important to your business or you are not really doing a great job looking after your business.
   I think it is logical to assume that the majority may have already gone through this process and that from middle of this year onwards we will be left only with 'laggards' category. These are generally (it is 'categorization', after all) reluctant people who, even if they choose Royale, will be less likely to act as advocates for Royale afterwards than the more 'innovative' people in earlier adoption categories.
   
   I also believe that we will get a lot more exposure, kudos and boost for Royale as a technology and as a brand for each external-facing app that can be migrated and associated with Royale compared with only internal-facing apps (e.g. intranet Dashboards etc) that relatively few people really get to know about (or that take a lot more effort to be able to share as 'success stories'). External facing apps are usually more business-critical and are already likely to be in migration planning and many will be underway if indeed they have not already been completed. 
   From our perspective in terms of marketing, 'Case studies' can be a lot more powerful if they are something you can visit via a url and see 'something' live (even if you can't see the more complex functionality that is only available via login). The same would be true for any newly developed app and not just for Flex migration apps, of course.
   
   You could argue 'chicken-or-egg' for any of this in terms of what should come first. But in simple terms my rationale for quick 1.0 release is:
   1. If we don't do it soon we will miss the last best opportunity to attract the people who are most likely to be able to contribute more and act as strong advocates for Royale. (I still believe that is Flex migration users)
   2. It is often not developers who make the final decisions about whether Royale is selected or not, so even if there is a good technical fit, other factors can exclude it. Business risks like developer pool size often come into play. In the absence of a corporate backer, an open source project can seem more risky if it does not have a large community. We need to arrive at a place where Royale is a lower risk option for decision makers. Growing the community (and developer talent pool) seems like a priority to me.
   2. 'Component sets' not being ready is not ideal but is not a reason to wait, IMO. Creating custom components is something people would be familiar with conceptually no matter what JS framework is used. I think we should continue to focus on legacy business logic continuing to work as it did before, that seems to be a well-received message for migration users, particularly if it can be demonstrated to them. It is unique to Royale. Beyond that, for components, we do need to make sure that people understand what currently works and what is yet to be done (docs) and I think a quick release cycle will help boost confidence (as Carlos mentioned). It might even be good to provide a simple visual cue for the state of each component set (think: progress bar, or thermometer bar just like you might see on 'PTA fundraisers' billboards for special school funding projects - in my country anyway, not sure about others). And ideally how folks can help with moving specific component sets forward (testing and creating issues, PRs, etc).
   
   /2 cents

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services