Thank you Howard for a great analysis and for pointing out the key problems.
Personally I think the top two problems are:
1- Bus number: we need to find a way to increase the number of active
maintainers to ensure the viability and velocity of the project
2- Sustainable revenue stream for maintenance activities: as you
explained, it is relatively easy to fund features, but profitable
companies selling software or services that use GDAL need to realize
that it would be an investment for them to contribute even just a
fraction of 1% of their sales in "non-string-attached funding" to
support non-sexy stuff such as release management, bug fixes, security
fixes, dependency upgrades, packaging, docs, etc... not only in GDAL,
but in the top-5 open source components that they rely on.
The QGIS approach to managing funding is an option, but it's not the
only one. I would tend to go for a more decentralized approach to reduce
the risk for the project with a single entity supporting it.
I step up to work with you Howard toward improving the situation.
(Actually I had already written personally to Even to discuss some
options before seeing your reply)
Daniel
On 2021-01-13 12:33, Howard Butler wrote:
Is there something fundamentally wrong with the current GDAL?
The project's history is one person doing most of the work. This person
eventually burns out.
Here's a table of the top five lifetime commits to the repository as of
December 2020.
Even Rouault – 19,838
Frank Warmerdam – 11,503
Kurt Schwehr – 3,403
Andrey Kiselev – 1,320
Howard Butler – 768
The reason why this person burns out is they are actually doing *three*
jobs, not one. Three, you say?
First is the actual maintainer job. You're the clearinghouse for bugs,
the primary authority on the mailing list, the first respondent in the
bug tracker, and the one that organizes and cuts the software release.
When we think of the maintainer for the GDAL project, this is what we
think of. No one organization will pay for just this job.
This means you need a revenue stream to make it maintenance your full
time gig. That's easy enough, just get paid for working on GDAL, right?
Well sure, but people don't want to pay for you to fix bugs that users
vaguely provide in the mailing list. They want to pay for functionality
they need to add to their software. So you are in a spot – you have to
*add* more to the software to earn revenue. For GDAL, adding more means
more drivers and more capabilities for those drivers (CPL, VSICloud,
etc). This creates more bugs and maintenance load that the original
directed funder supports for only a little while. This second job is in
conflict with the first and the dissonance amplifies as time goes one.
The third job is you have to solicit work through the contacts you've
built up to keep the revenue hopper full. Invoicing, statements of work,
negotiation, telecons, and the usual business stuff. People see you as
cheap because you're "open source", and pressure you on price, scope,
and completion time. You eventually orient about a small cadre of repeat
clients with strong trust relationships.
How can this be fixed?
1) Burn through the current maintainer and hope another one comes along.
The users of the GDAL project simply got lucky that Even picked up the
torch after Frank moved on. Maybe that happens again on the next iteration.
2) Refactor the software so that more maintainers can participate.
That's been our current discussion, which doesn't seem to be converging
on any solutions.
3) Provide a revenue stream so the maintainer only has to do the
maintenance job, and not the other two jobs that are in conflict with
the project's maintenance. This person should be paid like the FAANG
senior engineer that's currently taking GDAL and using it to add some
geo widget to their software.
OSGeo was supposed to be the answer to #3, but in 15 years of existence
it has shown it is not and never will be. Maybe it is time to start a
GDAL foundation ala QGIS and others and direct corporate benefactors to
fund it directly. Those benefactors would have to pledge significant
resources to at least get to the level of a FAANG senior engineer as a
start.
Howard
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
