You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by "Justin M. Hill" <Ju...@Prominic.NET> on 2019/04/29 17:40:19 UTC
Get paid to help bring Apache Royale to version to 1.0 -- submit your bid
for assistance to the group by Friday May 3
Royale helps modernize Flex applications AND provides a great alternative
to revitalize the next generation Flex ecosystem as a viable alternative to
Javascript solutions such as React, Angular, and Vue.
Get paid to help bring Apache Royale to version 1.0!
If you are interested in getting paid to help bring Royale to market as 1.0
then:
1) join the dev@royale.apache.org mailing list
2) review the recent discussions on what needs to be fixed on Nabble:
http://apache-royale-development.20373.n8.nabble.com
3) Submit to the dev@royale.apache.org mailing list your bid for assistance
to the group by Friday May 3
The Moonshine-IDE.com team is willing to donate $2,500 USD in total over
the next 30 days to anyone who can accomplish what Alex and Carlos want to
see happen to call it release 1.0.
IF you who are willing to step up to the plate immediately (with a
deliverable no later than May 26, 2019) to help with:
* documentation (ASDoc style)
* examples (code snippets that do things like Tour de Royale)
* tutorials (well written, friendly, understandable, educational material)
* a mini reproduction of the aforementioned Flex In a Week Series (great
idea!)
https://www.adobe.com/devnet/flex/videotraining.html
* build automation
* automated test cases
* creation of a summary comparison table showing Royale relative to React,
Vue, Angular
* a longer write up of competitive articles detailed why Royale is
important. BTW, one reason it can be important is because it is NOT
controlled by giant companies.
* a directory of consultants for hire:
* OR anything else Alex and Carlos specifically need to be convinced to
push to 1.0 release
THEN
Please submit to this public group your commitment and cost.
We will then do this democratically:
deadline for bid submissions is 7 days from now -- Friday May 3.
Carlos (or someone who knows Twitter enough to create another poll) will
then do another Twitter vote poll for 3 days to decide who gets the bids
Ideally multiple people will commit to doing something "small" for $500
each and we can award 5 people the projects.
The $2,500 USD total will be paid via PayPal. No exceptions.
IF within 30 days Apache Royale 1.0 is released to the public then the
Moonshine-IDE.com team will again donate $2,500 for the month of June in an
identical voting scenario (assuming this one works well) to bring home a
1.1 release.
By 60 days from now, a new user who has never seen Royale before or
programmed in ActionScript should be able to:
1) Arrive at the Apache Royale web page
2) Understand from the home page why they should care about the project if
they come from React, Vue, Angular, Flex, or ActionScript worlds
3) Be able to within 5 mouse clicks (download button, install button,
launch button, build button, run button) go from having nothing on their
machine to having an IDE (we of course volunteer Moonshine but Visual
Studio Code should be a goal for this, too) on their machine with a
successful build of their first "hello world". No command line nonsense.
No learning NPM, Git, downloading 20 required packages. See Royale
website. Want to try it. 5 clicks later build your Hello World.
If the above 3 goals are met, then the Moonshine-IDE.com team will run a
3rd donation round of $2,500 for the month of July in a manner to the
description above to bring home a 1.2 release, to be published no later
than the end of July 2019 for the awards to be paid.
Hopefully this helps motivate the team.
Thank you,
Justin Hill
Re: Get paid to help bring Apache Royale to version to 1.0 -- submit
your bid for assistance to the group by Friday May 3
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Flex folks,
First, we should thank Justin Hill for his generous offer.
This offer turns out to be a good opportunity to educate and/or remind folks how Apache projects are different from corporate-driven projects. Here's my take on some of important principles at Apache. Other Apache folks may have different opinions.
1) The Apache Software Foundation (the ASF) itself does not pay people to contribute to its projects. So the subject of this email is a bit concerning since it could imply that. But in this case, a company (Prominic) or a person (Justin Hill) is proposing to pay for contributions just like anyone hiring a contractor or employee. Which is totally fine and in fact, encouraged. It would be great if all of you who are planning to use Royale would pay for contributions as long as you make it clear that the ASF is not the entity paying. This includes, of course, contributing patches or features to Royale that you write yourself (where you are paying yourself or your employer is paying you). Royale is free software, but Royale will be better if every user finds a way to contribute. There is no big corporation like Adobe putting in money up front to try to guarantee success. This is more like a potluck than a restaurant.
IMO, it is fine for now for folks to post job offers on the mailing lists. If we get too many job offers, we can ask for a separate mailing list or some other place to share job information, but for now, I am personally ok with having offers of work-for-pay posted on the list with a [JOB] prefix. Others are welcome to object or propose other ideas. But basically, we want to encourage the growth of the Royale job ecosystem without implying that Apache pays for contributions. So in the future, please use [JOB] or whatever we converge on to distinguish that someone else is paying.
And that leads to point 2...
2) Work paid for by someone else is not guaranteed to be accepted into the codebase. Whatever code or other IP is paid for and generated (documentation, graphics, videos, etc) might be rejected just like any other code contribution from a committer. Rejections should be very rare in Royale as we have designed Royale to be loosely-coupled so the impact of some code on other code should be minimized. But the fact remains that if a contribution does not have technical merit or has licensing issues it may not be accepted and certainly not because someone paid someone for it.
One reason something could be rejected is because of point 3...
3) Apache does not want to appear to be influenced by corporations and business. What this really means is that no business entity should appear to be running the project, dictating schedules, roadmaps, etc. Apache is all about individuals. The person with a few hours on the weekend should be able to contribute. Of course, businesses with more money can pay more folks to write more code and overwhelm the weekend person. That's just life. But that business cannot reject the weekend person's contribution just because it doesn’t fit into that business's goals/schedule. And, no business can claim to be "the provider", "the sponsor", "the home of", or use similar phrases to imply that they are the sole entity in charge of the project. So if a paid contribution implies something like that, that would be grounds for rejection.
Similarly, because Apache is about individuals, we get to point 4...
4) No individual has more influence than any other individual. No matter who pays you or how many hours you have to contribute or whether you contribute documentation or code or help answer questions, you have an equal voice. Sure, there will be technical experts on subsections of the code that have a vision of what that subsection should do, but that's why Royale is loosely coupled: so you can fork that subsection and create your own variant. Royale itself probably won't designate one component set as "the one to use". There are many to choose from with pros and cons for your needs. And thus, it isn't up to Carlos or me or any other person to dictate what is or isn't going to happen.
Instead, projects get work done in a different way...
5) Apache projects use consensus. Without a boss to make the call, Apache projects rely on consensus (actually, general consensus) to make decisions. That can take more time when everyone has an equal say, but there really aren't other options. So if you have an idea to help Royale, post it and neither Carlos nor I will make a decision on it. We may voice our opinions, but it will be up to everyone else reading this email list and maybe responding to twitter posts to make it clear which ideas are most popular. And then, since Prominic or Justin Hill is paying, ultimately it is his call which ones to actually pay. We want whatever he pays for to have a return on investment for him so he has money to pay for more work. And the same goes for anyone else who can make a generous offer similar to Justin Hill's.
And similarly, without bosses and only individuals...
6) Apache projects generally don't have schedules/deadlines/roadmaps. There is no one in the project who can fire you for not making your deadline. We want to encourage folks to contribute even in their spare time. So Apache projects generally don't manage detailed schedules like you've probably experienced in other jobs. We have general goals, like there is general consensus to get to a 1.0 as soon as possible, but we can't set a date and manage towards it since there is no manager. We can shoot for a date, but if we don't make it, we don't make it. Now if some business or individual REALLY needs to hit a date, they can pay folks to try to get more work done by that date. But Apache and the project itself can't dictate to others what to do by what day. Or even what features are in or out. If someone wants to contribute something that is important to them but not to anybody else, it will go in based on its technical merit, not some strategy document. And that is to everyone's benefit. If you've ever posted a bug report or feature request to some provider hoping it will be in their next release, then you can see the benefit of the Apache model. At Apache, you can fix the bug or implement the feature yourself and if you've earned committer rights, it is in the next release. Or pay someone to fix the bug or implement the feature. Nobody can tell you otherwise (unless it creates a conflict for someone else).
Oh, and one more thing...
7) Apache is a non-profit so it cannot do certain kinds of marketing. However, individuals and business can, just not on the project's web presence. So factual comparison tables are probably ok on the Royale site, but once you get into opinions, that is best left for individuals and business to explain on their blogs and web presence why they chose Royale over some other technology.
So, in the end, Justin's email and future emails from others like this should read more like below.
Thanks,
-Alex
-------------
Subject: [JOB] Prominic hiring contractors to bring Apache Royale to version 1.0
Royale helps modernize Flex applications AND provides a great alternative
to revitalize the next generation Flex ecosystem as a viable alternative to
Javascript solutions such as React, Angular, and Vue.
Get paid to help bring Apache Royale to version 1.0!
Prominic is the company developing the Moonshine IDE for Flex and Royale.
Prominic is willing to pay developers to help bring Royale to market as 1.0. To apply:
1) join the dev@royale.apache.org mailing list
2) review the recent discussions on what needs to be fixed on Nabble:
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=gC1rfZiIcxvWM9NePG0GdsjNl6iFMkmKfbdrcn7vQK8%3D&reserved=0
3) Submit to the dev@royale.apache.org mailing list your bid for assistance
to the group by Friday May 3
The Moonshine-IDE.com team is willing to donate $2,500 USD in total over
the next 30 days to anyone who can accomplish agreed upon tasks
to help Royale release a 1.0 version.
IF you who are willing to step up to the plate immediately (with a
deliverable no later than May 26, 2019) to help with:
* documentation (ASDoc style)
* examples (code snippets that do things like Tour de Royale)
* tutorials (well written, friendly, understandable, educational material)
* a mini reproduction of the aforementioned Flex In a Week Series (great
idea!)
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.adobe.com%2Fdevnet%2Fflex%2Fvideotraining.html&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=ehetZFgS6Tn9fR0PbFGjKh2yILbeKnKKhfV8ChhM9SA%3D&reserved=0
* build automation
* automated test cases
* creation of a summary comparison table showing Royale relative to React,
Vue, Angular
* a longer write up of competitive articles detailed why Royale is
important. BTW, one reason it can be important is because it is NOT
controlled by giant companies.
* a directory of consultants for hire:
* OR anything else you would want to see in a 1.0 version of Royale
THEN
Please submit to this public group your commitment and cost.
We will then do this democratically:
deadline for bid submissions is 7 days from now -- Friday May 3. Folks on this mailing list should offer their thoughts and opinions on the bids.
Carlos (or someone who knows Twitter enough to create another poll) will
then do another Twitter vote poll for 3 days to see what folks think of the various proposals. Prominic alone will decide which bids it will pay for taking into consideration the discussion threads.
Ideally multiple people will commit to doing something "small" for $500
each and Prominic can award 5 people the projects.
The $2,500 USD total will be paid via PayPal. No exceptions.
Please note that the work you do may not be accepted into the project repos. If your work is not accepted, Prominic will work with you and the project on next steps. Your work may end up on the Moonshine-IDE site or other places. Prominic cannot dictate production deadlines for an Apache project so If the 30 day and 60 day deadlines are not met, Prominic reserves the right to change the offer or its deadlines. Prominic is not the only business entity involved with Royale and encourages other business entities to make similar offers to help Royale mature to be your solution for building applications for web/mobile/desktop.
IF within 30 days Apache Royale 1.0 is released to the public then the
Moonshine-IDE.com team will again donate $2,500 for the month of June in an
identical voting scenario (assuming this one works well) to bring home a
1.1 release.
By 60 days from now, a new user who has never seen Royale before or
programmed in ActionScript should be able to:
1) Arrive at the Apache Royale web page
2) Understand from the home page why they should care about the project if
they come from React, Vue, Angular, Flex, or ActionScript worlds
3) Be able to within 5 mouse clicks (download button, install button,
launch button, build button, run button) go from having nothing on their
machine to having an IDE (we of course volunteer Moonshine but Visual
Studio Code should be a goal for this, too) on their machine with a
successful build of their first "hello world". No command line nonsense.
No learning NPM, Git, downloading 20 required packages. See Royale
website. Want to try it. 5 clicks later build your Hello World.
If the above 3 goals are met, then the Moonshine-IDE.com team will run a
3rd donation round of $2,500 for the month of July in a manner to the
description above to bring home a 1.2 release, to be published no later
than the end of July 2019 for the awards to be paid.
Hopefully this helps motivate the team.
Thank you,
Justin Hill