Thank you Howard, Daniel, Jukka, and others.
When I google for qgis I get its page and six sub pages in the way
Google does it. One of those is "Donations". When I do the same for
GDAL, there's no such page. I guess the first and practical thing to do
would be to make regular donations possible. The second thing would be
to advocate companies/people to make donations without strings attached.
That's already much in the domain of OSGeo, but the first thing is quite
much in the project's domain.
Best regards,
Ari
Daniel Morissette kirjoitti 13.1.2021 klo 21.11:
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
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
