> I am talking about *user* companies here Of course this is (as I wrote) a perfectly valid case - and it works beautifully in many cases. I know plenty of examples :). Maybe there was a misunderstanding of my "(unlike the models 2. 3)". I think those models were (and still are) crucial to the success of many projects. And I think there is no argument about it. I am not sure if this is some kind of argument we are having or whether we agree so let me reiterate what I thin I want to say in the context of the topic of the discussion. Just to remind the topic: "Effective ways of getting individuals funded to work on ASF projects"
Both 2) and 3) contain "employers" who pay their employees or allow them to scratch itches independently and I am not sure if ASF can help here somehow in making it "better". On the other hand my proposed "model 4)" is different and I believe ASF **might** play some role in making it easier for both individuals and stakeholders. In this model, you have no "employees". You have stakeholders reaching out to individuals - committers/PMC members/contributors who are already working on the project (or the other way round - it could be committers reaching out) to pay them. All this without a pre-existing Employee <-> Employer relationship. I think this is the very model that the ASF can help to "facilitate" establishing such relationships (which is the most difficult and crucial part of making the model works). * make both individuals and stakeholders aware it's OK and what are the conditions (for example making sure there is "no non-compete" and "community makes decisions" clauses) in such relationships * show the path how both sides can act to establish relationship between them and what could the "protocol" there * provide some guidelines on how contracts should be written (without providing legal advice of course as ASF can't do that and those will be subject to local laws especially in case of IP clauses there) * possibly provide a list of intermediaries that can help with the "bureaucracy" (handling invoices, signing, preparing contracts etc.) I think if we are (at least that was the initial topic) discussing ways "how we can improve the situation as an ASF" - this is my thinking where it could help - specifically in model 4. I am also happy to help prepare some of that (following Roman's proposal). For example I am - as we speak - discussing some details with my lawyers (who actually specialise both anglo-saxon and east-european IP law) about some IP clauses in my contracts that I am sending to a new customer. And while I can afford that and have friendly lawyers whom I trust with it, and I run a business before, so I know you need to involve lawyers there. I am sure that might be one of the obstacles for multiple individuals who would like to set up similar, direct contracts with the stakeholders, but do not know where to start and what to look for - I think sharing some outcome and guidelines here might help. J. On Sat, Mar 5, 2022 at 12:32 AM Phil Steitz <p...@steitz.com> wrote: > > 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 > >
