[gdal-dev] Driver maintenance - long-term solution ?

[Paul Harwood]

Having thought about these comments ...

As in most things - we need to be clear about what it is that we actually
want :

- If the thing is that FAANGS (and apparently gov organisations) need to
feed back into the products that they use then the way that they do that
and can easily is to provide tools and services (let's remember that GitHub
is provided free by Microsoft, Bootstrap by twitter, React by Facebook,
Angular by Google, Typescript by MS etc etc etc - Google also provides a
lot of compute time for free using quotas etc etc). They can also pay
individuals who are allowed to contribute to projects. But I don't think
this is the subject of discussion.

- If what we want is that the people running GDAL get paid (I am going to
deliberately talk in the abstract not through ignorance but to avoid the
personal) then we have to understand that this is employment. That comes
with its own set of laws and regulations.

-- One way is to approach the biggest user and propose that they employ the
people involved full-time or part-time on running GDAL. That is actually
relatively easy for them to do inside the team and is done a lot. But - it
is possible that the people involved don't want to work for that company.
It also depends on getting to the right decision-maker to make the case and
indeed on that team caring that the software exists etc etc. However, it is
easy and normal practice with no legal minefields. Think Guido and Python
with Google - then DropBox - then Microsoft etc.

-- If not that then the people involved could get paid for contract work
using the usual well-established mechanisms. But a contract has to have a
scope. That comes back to "they are OK paying for enhancements". Placing a
contract for a company (even if just one person) to create an enhancement
is business as usual for any company.

-- If not that you either create a GDAL company and employ the individuals
and charge the customers (i.e. no longer FOSS) or you create a foundation
and employ the people (either directly or by contract) which then comes
back to Hobu's original question.

Perfectly possible and FAANGs can give donations to foundations. Usually
only (since the FAANGs are US based) if they are based in the US and have
passed 18 months of due diligence vetting! That is just life. A foundation
can do a deal with another foundation - there are actually foundations in
the US that specialise in getting money from FAANGs since they are DD'd up
the wazzoo and then placing contracts with other foundations to fund them.
This is kind of where organisations like OSGeo or NumFocus should come in.
Never seems to work like that.

It should be noted that a Foundation that employs people (directly or
indirectly) is not a simple thing to run. It comes with its own mass of
paperwork.

- If we just want to spread the workload and decrease the bus number, then
by the art of the possible, we should refactor to make it easier for more
people to work on it and then have a proactive campaign aimed at the
individuals and teams in large user organisations to get them involved in
running components. In the FAANGs an engineer could spend 20% of their time
on that without even needing to get permission and more would just be a
team leader decision based on what makes sense for the team. You are, of
course, at the mercy of product deadlines but that is true for the rest of
us as well.

As for the "threaten the end of the project" approach. I would say never
threaten anything that you are not completely willing to follow through on.
If it is true, then it is true, but not otherwise. As a Senior TPM, my
response would have been to fork the code and run it internally using team
resources - you might think of a "gooGDAL". Not out of any wish to be evil
but just from the art of the possible - internal resources are a team level
decision but funding an external FOSS project is not. I am sure we would
even have made the results publicly available - but the new product would
have been run to internal project requirements.

On Fri, 15 Jan 2021 at 22:25, Stephen Woodbridge <
stephenwoodbridge37 at gmail.com> wrote:

> So reading through this thread, my cynical side agrees with the "this
> project is dying from lack of funding, ..." approach, but I'm not sure
> that works for the long run as people get tired of hear the "sky is
> falling" and ignore it over time.
>
> A different approach could be something along the lines of what AARP
> does, to get it members to email congress representative to lobby for
> support. OK, this might sound crazy and it would require some
> coordination but might work like this:
>
> 1) we get government agencies that use GDAL and more broadly OSGeo push
> up the chain of command the need to support opensource projects and the
> current issues in doing so
> 2) we put a support web page the allows community members and public to
> email a form letter to their congress people explaining that a large
> number of government agencies (probably need a list of them) need and
> use opensource software but are not able to support the development or
> maintenance of. This is a critical issue around the US being a leader in
> opensource development. If this software becomes unavailable or
> unsupported that it puts these agencies at risk, blah, blah, blah
>
> Apologies to reads in other countries that disagree with the statements
> above, this is an appeal to US congress, so its slanted in their
> direction. No offense is meant here.
>
> Likewise, this could be done in other regions/countries that rely on
> this software.
>
> Commercial companies spend money on lobbying and sales calls so maybe we
> need to find a strategy that works for opensource.
>
> Anyway, it's an idea, maybe it's not workable because we don't have
> funding to put something like this in place or people don't think it is
> of value. I don't think this should be done at the GDAL level, but maybe
> at OSGeo and maybe in coordination with other opensource organizations.
> So just putting another idea out there.
>
> -Steve W
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210116/3f17c1fc/attachment.html>