>
>
> I guess my point about this is, that small startups usually have problems
> of getting contracts.
>
> I can't count the occasions, where I generated leads at a conference.
> After the conference, when we were discussing moving forward, 95% of all of
> these died because the customers can't do business with such small
> companies.
>
>
This is also my assessment of where the problem is. I think building
relationships and finding customers in an OSS world is relatively easy if
you are transparent, honest, do your job well and you are open to speak,
you make sure you stand out of the crowd and you are generally proud of
what you do (yes Chris - those all things are about you too :D).
It's turning them into a regular invoice paid every month is where the
difficulty is.
However I think we need to really understand where the "can't do business"
comes from. My view on this:
1) The businesses have established procurement processes and you have to
"fit" - in most cases there are a number of conditions:
- you have to "be on the list" of the approved vendors
- in many you have to sign certain agreements that you do not "child
labour", "bribery" etc. and similar thing (basically because public
companies have to report that their vendors are "ok" to the auditors
- in many cases the business have to have someone to "sue" in case
there is a damage or have some other indemnification in place - (what if
the vendor does harm to our customers and we get sued)
- there is also a check who is the beneficiary owner (money laundering)
W1-BEN forms in US when you have "individuals"
- also - and this is more important recently - there is a check if your
company does not fall into any of the sanctions imposed by the political
decisions
- there are a number of legal requirements (TAX Id registrations etc.)
Having an entity that is "known" to the customer and "big" and can provide
such guarantees is crucial otherwise it's a big effort to pass that step.
Here Both "Support Inc." and "Open Collective + ASF as fiscal host" - if we
can think about the two models, would likely work well. The "burden" of
verifying those is shifted to OpenCollective and ASF joint effort and I
think it should be feasible to put both OC and ASF as "accepted vendor
combo" for most big players. And for each player it would have to be done
once to enable all projects basically.
2) We also have to remember that people who we contact as potential
customers often are not familiar with those processes - and even if they
"want" to work with you - this might be the first time they approach it and
it can take them MONTHS to get it sorted out.
I can - again - give a very good example. I mentioned "contract"
negotiations before - and it is an interesting one. The prospective
customer people really wants to work with me. I really love what they do
and I have great contact there who is willing to take on all the complexity
of managing the OSS <> Company relations between me and the company - we
are also friends and worked together on a number of initiatives in the
project (successfully) and we both want to work together. And the manager
of my friend and his manager are fully supportive. And ~ 2 months ago the
joint statement was "we really want to start working together basically
next week". We still have no contract signed today. We know the price, we
know how much time I will focus on with the customer, we know what the
needs of the customer are. We know big parts of it will end up as good
community contributions. EVERYTHING is in place. But they never ever had a
contract with someone like me. I have a requirement that the contract from
the customer is explicit about my ICLA (and my self-owned company CCLA) and
this is with the lawyers of the company now.
Here - this is something that 1) will make easier - because (hopefully) we
could work out a template contract and having bigger entity (whether
Support Inc or OC + ASF Combo) we could probably have some established
"service" with all the documents prepared, and all the answers given and
even some guidance to our "partners" at the corporates on how they can
clear their processes faster. But there is one caveat (see point 3) as our
relation is a bit different.
3) The 2) might take much longer mostly because we - OSS contributors -
have a different type of relationship than regular vendors. For most of the
vendors, big businesses have some expectations that we cannot meet and we
fall into "legalities" and contract signing.
There are two kinds of those:
* we cannot guarantee that whatever the customer wants will be fulfilled
when we contribute to ASF projects. Most big players look at such a
relation from "I pay - I demand" and most of the internal audits will have
a hard time on accepting a contract where there is no "deliverable" that
the company can "demand to complete". I found this extremely hard to
negotiate in the past. Usually it ends up with some kind of "blurry"
statement which can be interpreted differently and both parties (usually
mostly vendors) have to accept the risk that if the other party wants -
they can "exercise" some statements "But you have not delivered this - you
promised it in contract". Bue t over the last few years I actually managed
to convince some of the parties I work with to put some explicit statements
that "the work is subject to community rules ..." and I am for one - super
happy with the contracts I have now - because it does not put an obligation
on me that I cannot fulfill
* and there is the bigger problem about IP. Basically for pretty much all
the customer <-> vendor relationships almost by default you have that "all
the IP produced during the relation belongs to us". Which is - IMHO against
the Apache Way and against the ICLA and CCLA that we have with ASF. When
you develop a code in the ASF you contribute it to ASF as an individual.
This is a bit blurry in the current approach because (at least this is how
I understand it) ICLA governs my individual contributions, while CCLA
governs contributions of your employees. But when you have a 3d-party
vendor (And I am not a lawyer so I might be wrong about this) - even if the
CCLA is signed with the ASF by the customer, it does not automatically
apply to a vendor <> customer relationship. So if I sign a standard
agreement that customer "usually" signs with the vendor - all the IP
belongs to the customer - and I cannot legally contribute it to ASF without
explicit permission for every contribution by the customer. Which is
definitely wrong and puts me under a huge legal risk if I actually
contribute some code that was created during that relationship - because
the customer might claim I should not do it. This is actually why I have
not signed the contract with the new customer yet - because the contract I
got from them (as opposed to my proposal) did not contain explicit
mentioning of the ICLA/CCLA I personally and my own company has signed with
the ASF and that the code contributed this way does not belong to the
customer.
Here I think "Support Inc." is at disadvantage over the OCC + ASF combo.
The problem is, that if "Support Inc." will be "just another company" -
there will be no way it could negotiate either the "demand" or the "IP"
part with the big customers IMHO. They will treat it as a "regular" vendor
and will expect it to provide the usual "all code belongs to us" and
"deliverables you have to fulfill". Surely the "Support Inc," **could**
agree to that and have different agreement with the contributors, but that
would be an enormous business/legal risk to take that on (and it would not
be transparent and well, even possibly dishonest - promising something you
are not able to promise and claiming that the code belongs to you where it
does not). But with the OCC + ASF combo, there is a chance that the same
negotiations I did with my customers and the same "explicitness" in
contract might be agreed to. That needs some legal/contract etc. work, but
it has a chance to scale well - because unlike "projects scope" those
provisions would be identical for all projects participating. And if the
OCC + ASF combo would also become "known" and signs similar agreements with
one or two big players, transferring it to the next players might become
easier and make a "snowball" effect. The nice thing about it is that it has
"special" status - without - I think breaching the bylaws and approach of
ASF when it comes to non-profit status.
Now - we can see those three approaches I think:
1) ASF does all the work, establish the payment structure and invoicing but
also starts being the intermediary of the project <> customer relationship
- this is not possible due to non-profit status of ASF as I see it and as
has been said multiple times
2) Support Inc. is established - but it can't be endorsed and it's hard to
say how it can have "special" status that would make the negotiations with
the customers on the demands and IP
3) OCC (or other similar) + ASF as "fiscal host" combo - this has at least
a chance (subject to legal review and by-laws and likely some
interpretations) of providing the right legal + accounting framework
(fiscal host) while out-sourcing the customer <> contributor relationship
to OCC but keeping the "reputation" and "special status" allowing to build
a scalable and repeatable framework for multiple projects to tap in.
Of course - maybe it's just "legal optimization" and trying to shuffle
things around, and maybe it does not have a "legal ground" - because there
might be some "implicit responsibilities" that the ASF might not want to
take in such a combo. But at least from the first glance it looks like it
might work.
J.
