Re: Effective ways of getting individuals funded to work on ASF projects
On 3/4/22 11:28 AM, Jarek Potiuk wrote: Definitely another good way to support projects. I think 2. and 3. originating in user companies can actually help foster vendor neutrality as these companies are really just users. Whether the people are employees or contractors is not important. What *is* important is that they have time and mandate to contribute broadly to the project rather than just trying to get specific features in. There is a huge difference actually. Employees - almost by definition - cannot work for competitors at the same time. Individual contributors can. I am talking about *user* companies here - companies that do not directly make $ on the software being produced by the project. However they pay - either employees or contractors - they are going to protect their proprietary IP and they need to have policies around that, but in the vast majority of cases for actual user companies, this is irrelevant. There are a *huge* number of companies that use ASF and other OSS software that do not compete in any way shape or form with the various vendors involved in the projects. I am talking about those companies - the actual users of the software. It is very possible for these companies to employ people and allow and encourage them to contribute *independently* to OSS, sometimes scratching work-related itches, sometimes just doing what needs doing. I know that seems a slightly foreign concept these days, but there have been a whole lot of people over the years who have done exactly this. The nice thing about working for a company that actually uses the software is you get a clear picture of what is important. Your direct experience using and supporting the software comes directly back into the project. As I said, our projects used to be full of people like this. One of our most successful early Java projects - Struts - had no vendor-paid developers when it became the leading Java MVC framework. The committers all used struts in @dayjob, but they were actual users. As we have become more vendor-dominated, contributors like that have become more sparse. That does not mean though that this it is not a vast resource of potential contributors and a good way to get paid at least partially to work on OSS. Phil As a contractor (and that also should be part of any other contributor's clause) I can work with multiple stakeholders - even competitors (and this is an important clause that I make sure in my contract). Currently, as an independent contributor i have/had business relationship with: * Google * AWS * Astronomer (And some more are coming). They are competitors, buti also they are cooperating on Airflow - so called "coopetition". This is next to impossible for an Employee to have several employment contracts with competitors at the same time. Also it allows me to lead projects and initiatives, where there is a value brought by all those different stakeholders. Being independent and paid by all of those make it also easier for other stakeholders to join the efforts. This is all extremely different to situations where the people contributing are employed by a single Employer. That also works - of course, and there is nothing wrong with that. But it is very different. J. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Effective ways of getting individuals funded to work on ASF projects
> On Mar 4, 2022, at 10:28 AM, Jarek Potiuk wrote: > >> Definitely another good way to support projects. I think 2. and 3. >> originating in user companies can actually help foster vendor neutrality >> as these companies are really just users. Whether the people are >> employees or contractors is not important. What *is* important is that >> they have time and mandate to contribute broadly to the project rather >> than just trying to get specific features in. This is a subtle and important point. - how do vendors enable their individuals to upstream changes? - how easy does the project make it for individuals to upstream their changes? > > There is a huge difference actually. > > Employees - almost by definition - cannot work for competitors at the > same time. Individual contributors can. That depends on the terms of employment. I’m employed currently and explicitly expected to contribute. This hasn’t always been the case. > > As a contractor (and that also should be part of any other > contributor's clause) I can work with multiple stakeholders - even > competitors (and this is an important clause that I make sure in my > contract). There are reasons for competitors to co-operate. > > Currently, as an independent contributor i have/had business relationship > with: > > * Google > * AWS > * Astronomer > > (And some more are coming). They are competitors, buti also they are > cooperating on Airflow - so called "coopetition". This is next to > impossible for an Employee to have several employment contracts with > competitors at the same time. This is how a vendor independent project ought to work. Perhaps a review of https://blogs.apache.org/foundation/entry/the-apache-way-to-sustainable ? > > Also it allows me to lead projects and initiatives, where there is a > value brought by all those different stakeholders. Being independent > and paid by all of those make it also easier for other stakeholders to > join the efforts. > > This is all extremely different to situations where the people > contributing are employed by a single Employer. That also works - of > course, and there is nothing wrong with that. But it is very > different. Everyone’s situation is uniquely theirs. All the best, Dave > > J. > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Effective ways of getting individuals funded to work on ASF projects
> Definitely another good way to support projects. I think 2. and 3. > originating in user companies can actually help foster vendor neutrality > as these companies are really just users. Whether the people are > employees or contractors is not important. What *is* important is that > they have time and mandate to contribute broadly to the project rather > than just trying to get specific features in. There is a huge difference actually. Employees - almost by definition - cannot work for competitors at the same time. Individual contributors can. As a contractor (and that also should be part of any other contributor's clause) I can work with multiple stakeholders - even competitors (and this is an important clause that I make sure in my contract). Currently, as an independent contributor i have/had business relationship with: * Google * AWS * Astronomer (And some more are coming). They are competitors, buti also they are cooperating on Airflow - so called "coopetition". This is next to impossible for an Employee to have several employment contracts with competitors at the same time. Also it allows me to lead projects and initiatives, where there is a value brought by all those different stakeholders. Being independent and paid by all of those make it also easier for other stakeholders to join the efforts. This is all extremely different to situations where the people contributing are employed by a single Employer. That also works - of course, and there is nothing wrong with that. But it is very different. J. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Effective ways of getting individuals funded to work on ASF projects
On 3/4/22 4:08 AM, Jarek Potiuk wrote: 1. We can all afford to volunteer our discretionary time as we see fit. Not just rich or retired people have discretionary time. 2. Employers can support OSS communities by allowing their employees to contribute as part of their jobs, but not in a "job shop" or directed way. 3. Employers can support OSS by allowing their people to scratch itches directly. I personally think there is a 4 th way. I discovered it ~4 years ago in Polidea, the software house I co-owned, worked on and sold and eventually turned it successfully into my personal "business model". This is is not at all obvious why it would work and it was a bit of surprise for me when I discovered it and when I successfully made living from it (and also successfully helped with upp-ing the value of the company I co founded so that it could be acquired) - at the same time contributing a lot to the success of Apache Airflow project which became the most contributed (in terms of numbers of contributors) project of the ASF. The model is: 4. Organization and stakeholders in the project, rather than paying their own employees, pay independent third-parties to contribute to the OSS (software houses or individuals). This all with understanding the limitations it brings in influencing direction of the project and recognizing value of the parties who are intimately familiar with not only code, but also community and simply are the best to "make things happens" - all according to the rules and limitations of the ASF and (unlike the models 2. 3. ) increasing vendor neutrality in the project rather than decreasing it. Definitely another good way to support projects. I think 2. and 3. originating in user companies can actually help foster vendor neutrality as these companies are really just users. Whether the people are employees or contractors is not important. What *is* important is that they have time and mandate to contribute broadly to the project rather than just trying to get specific features in. Phil I think this model makes it possible to kill two birds with the same stone: * make the model when you can make living from open source contributions * increase vendor neutrality in the projects It is largely described in the article which I wrote a few years back in Polidea and reposted it after Polidea has been acquired. Since then I learned (and tested on myself) that this is a sustainable model not only for 3rd party software houses, but also for independent contributors like me. https://medium.com/@jarekpotiuk/the-evolution-of-open-source-standing-on-the-shoulders-of-giants-db22dcdbca04 I really wish we could together find some ways to replicate that and make many individual contributors to follow this model. J. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Effective ways of getting individuals funded to work on ASF projects
> > 1. We can all afford to volunteer our discretionary time as we see > fit. Not just rich or retired people have discretionary time. > 2. Employers can support OSS communities by allowing their employees to > contribute as part of their jobs, but not in a "job shop" or directed way. > 3. Employers can support OSS by allowing their people to scratch itches > directly. I personally think there is a 4 th way. I discovered it ~4 years ago in Polidea, the software house I co-owned, worked on and sold and eventually turned it successfully into my personal "business model". This is is not at all obvious why it would work and it was a bit of surprise for me when I discovered it and when I successfully made living from it (and also successfully helped with upp-ing the value of the company I co founded so that it could be acquired) - at the same time contributing a lot to the success of Apache Airflow project which became the most contributed (in terms of numbers of contributors) project of the ASF. The model is: 4. Organization and stakeholders in the project, rather than paying their own employees, pay independent third-parties to contribute to the OSS (software houses or individuals). This all with understanding the limitations it brings in influencing direction of the project and recognizing value of the parties who are intimately familiar with not only code, but also community and simply are the best to "make things happens" - all according to the rules and limitations of the ASF and (unlike the models 2. 3. ) increasing vendor neutrality in the project rather than decreasing it. I think this model makes it possible to kill two birds with the same stone: * make the model when you can make living from open source contributions * increase vendor neutrality in the projects It is largely described in the article which I wrote a few years back in Polidea and reposted it after Polidea has been acquired. Since then I learned (and tested on myself) that this is a sustainable model not only for 3rd party software houses, but also for independent contributors like me. https://medium.com/@jarekpotiuk/the-evolution-of-open-source-standing-on-the-shoulders-of-giants-db22dcdbca04 I really wish we could together find some ways to replicate that and make many individual contributors to follow this model. J. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Commented] (COMDEV-454) Report Wizard gives "[object Response]" error with underlying 503
[ https://issues.apache.org/jira/browse/COMDEV-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17501222#comment-17501222 ] Robert Munteanu commented on COMDEV-454: This seems to be working now. > Report Wizard gives "[object Response]" error with underlying 503 > - > > Key: COMDEV-454 > URL: https://issues.apache.org/jira/browse/COMDEV-454 > Project: Community Development > Issue Type: Bug > Components: Reporter Tool > Environment: Mac/FF >Reporter: Shane Curcuru >Priority: Major > > As reported elsewhere, navigating to [https://reporter.apache.org/wizard/] > pops up a notification error, and does nothing else. > Console shows an underlying 503: > /*** ASF Board Report Wizard initializing / > [wizard.js:1792:9|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4] > Fetching JSON resource at /reportingcycles.json > [wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4] > putting /reportingcycles.json in escrow... > [wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4] > Successfully fetched /reportingcycles.json > [wizard.js:119:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4] > Fetching JSON resource at /api/overview > [wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4] > putting /api/overview in escrow... > [wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4] > URL /api/overview returned HTTP code 503, snapping! > [wizard.js:132:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org