On 3/5/22 12:08, Jarek Potiuk wrote:
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.

All good.  I did not mean to be argumentative - just to point out that it is possible to be funded to work on OSS without working for a vendor either directly or indirectly as a contractor.

Phil


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




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Reply via email to