[gdal-dev] gdal-dev Digest, Vol 200, Issue 29
mmfuller
mmfuller at protonmail.com
Thu Jan 14 04:33:01 PST 2021
Lurker here,
Having read through several (not all) posts in this thread, I have the feeling that the GDAL team is at a cross-roads.
It seems the main issue is that FAANG and a ton of startups, successful companies, etc are dependent on GDAL, but won't pay to support it.
What some groups do in this situation is to announce the imminent death, sorry, closure, of the repo. "GDAL will no longer be maintained after X date."
Now all those senior engineers run to their managers and say "We are about to lose a critical component of our software, with no available replacement"
"What?!" says the manager. "That is not acceptable! How do we prevent this?" to which the engineer says "We need to fund the GDAL team".
If enough companies have that conversation, realizing they are up sh*ts creek without GDAL, they suddenly find the funds to support it.
At least in theory. So basically, I'm suggesting presenting the software world with an ultimatum. Pay up or lose it.
Unethical? Immoral? Against the FOSS philosophy? Or just practical / realistic?
I don't know but given the current state of things (based on this thread), perhaps it's the only way?
Mike (one of those senior engineers)
PS: apologies if I'm making brash suggestions that have been debated in the past or just seem too outrageous
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 13th, 2021 at 11:33 PM, <gdal-dev-request at lists.osgeo.org> wrote:
> Send gdal-dev mailing list submissions to
>
> gdal-dev at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> or, via email, send a message with subject or body 'help' to
>
> gdal-dev-request at lists.osgeo.org
>
> You can reach the person managing the list at
>
> gdal-dev-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
>
> than "Re: Contents of gdal-dev digest..."
>
> Today's Topics:
>
> 1. Re: Driver maintenance - long-term solution ? (David Strip)
> 2. Re: Driver maintenance - long-term solution ? (Greg Troxel)
> 3. Re: Driver maintenance - long-term solution ? (Greg Troxel)
> 4. Re: Driver maintenance - long-term solution ? (Ari Jolma)
> 5. Re: Driver maintenance - long-term solution ? (xavier lhomme)
>
>
> Message: 1
>
> Date: Wed, 13 Jan 2021 17:03:54 -0700
>
> From: David Strip gdal at stripfamily.net
>
> To: Howard Butler howard at hobu.co, "gdal-dev at lists.osgeo.org"
>
> <gdal-dev at lists.osgeo.org>
>
>
> Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?
>
> Message-ID: 368fd9fc-e27e-b85c-9543-d74468b4ad8b at stripfamily.net
>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
>
> URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210113/bf854469/attachment-0001.html
>
> Message: 2
>
> Date: Wed, 13 Jan 2021 19:09:05 -0500
>
> From: Greg Troxel gdt at lexort.com
>
> To: Paul Harwood runette at gmail.com
>
> Cc: Carl Godkin cgodkin at gmail.com, "gdal-dev\@lists.osgeo.org"
>
> <gdal-dev at lists.osgeo.org>
>
>
> Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?
>
> Message-ID: rmio8hsl6qm.fsf at s1.lexort.com
>
> Content-Type: text/plain; charset="us-ascii"
>
> Paul Harwood runette at gmail.com writes:
>
> > I don't know the solution. The usual solution is an existing large,
> >
> > US-based foundation that has existing dealings with the FAANGS that could
> >
> > act as a conduit (perfectly legally).
>
> I'd like to thank Howard for speaking so clearly.
>
> One of the really broken things is that big companies seem to have a
>
> hard time making a donation to an open source project. Yet they can pay
>
> for proprietary software licenses with no effort. So I wonder if
>
> selling some kind of "gold support contract", would be viable, where all
>
> that they get is to put the gold label on issues on the tracker, but
>
> then it's a "support contract" and thus easy like a license, vs a
>
> "donation".
>
> I don't buy the notion that Sarbanes-Oxley makes this hard. I think
>
> that's just an excuse, based on my experience.
>
> -------------- next part --------------
>
> A non-text attachment was scrubbed...
>
> Name: signature.asc
>
> Type: application/pgp-signature
>
> Size: 194 bytes
>
> Desc: not available
>
> URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210113/41afaa98/attachment-0001.sig
>
> Message: 3
>
> Date: Wed, 13 Jan 2021 19:31:01 -0500
>
> From: Greg Troxel gdt at lexort.com
>
> To: David Strip gdal at stripfamily.net
>
> Cc: Howard Butler howard at hobu.co, "gdal-dev\@lists.osgeo.org"
>
> <gdal-dev at lists.osgeo.org>
>
>
> Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?
>
> Message-ID: rmik0sgl5q2.fsf at s1.lexort.com
>
> Content-Type: text/plain; charset="utf-8"
>
> David Strip gdal at stripfamily.net writes:
>
> > License monkey business isn't viable in any way with
> > GDAL. It would just create confusion and erode trust, which we
> > can't get back if broken.
> >
>
> Strongly agreed.
>
> > gdal wouldn't be the first project to change it's license, though I
> > really don't know enough about the consequences others have faced
> > for doing so.? Even the revered GPL is a moving target.
> > If the alternative is a burned out lead developer/maintainer and a
> > dead project, that's not a desirable outcome either.
> >
>
> My impression is that every project that has tried to play games with
>
> open source licenses has basically been a one-company project, and that
>
> this has led to shunning.
>
> > I'm not sure I agree that changing the license would create
> > confusion and erode trust. Assuming that we (whoever "we" are)
> > actually have the legal right to change the license, let's play a
> > hypothetical.
> >
>
> The only projects that can arbitrarily change license are those in which
>
> The copyright is held my one company or a small number of people.
>
> This is why projects that pretend to be open source and ask for
>
> assignment of rights to a company are problematic.
>
> There are a small number of contributors who would agree.
>
> Projects that are e.g BSD licensed that want to move to GPL. The old
>
> code remains, but the new code has a copyleft.
>
> > The new license maintains fees from two classes of users:
> > 1. Anyone incorporating gdal into a product that is
> > ???? a. not completely open source,? and
> > ??? b. charges a license fee (perpetual or subscription), and
> > ??? c. has more than x active licenses (x = 500? 1000?)
> > 2. Any for-profit organization utilizing gdal in-house for data
> > analysis, conversion, on-line services,? etc, in excess of x CPU
> > hours per year (where y = 1000? 5000?...)
> > 3. Any organization that uses gdal indirectly through a free, open
> > source product (eg, QGIS) or a licensed product covered under 1)
> > above is exempt from 1) and 2).
> >
>
> That's obviously no longer open source.
>
> > I don't think I need to name names - you know who the big players
> > are in categories 1 and 2. Only two in category 1 and none in
> > category 2 stepped up with a large (relative to the ask) commitment
> > in the previous barn raising.
> >
>
> I think you should name names. It's not helpful to pretend we shouldn't.
>
> > ?Equally, the vast majority of users will have no question that they
> > continue to operate in the free range. Given that this whole thing
> > started with a suggestion that the only way to make users aware of
> > deprecation of obsolete drivers was to make the drivers stop
> > working, how many users will even be aware of a license change?
> >
>
> This will cause binary gdal packages, and everything that depends on
>
> them, to get kicked out of first-class status or dropped from many
>
> packaging systems.
>
> -------------- next part --------------
>
> A non-text attachment was scrubbed...
>
> Name: signature.asc
>
> Type: application/pgp-signature
>
> Size: 194 bytes
>
> Desc: not available
>
> URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210113/a443e9a5/attachment-0001.sig
>
> Message: 4
>
> Date: Thu, 14 Jan 2021 08:05:51 +0200
>
> From: Ari Jolma ari.jolma at gmail.com
>
> To: gdal-dev at lists.osgeo.org
>
> Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?
>
> Message-ID: 43684ece-6cca-b322-53b6-7cf899c0d385 at gmail.com
>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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
> > >
> > > gdal-dev at lists.osgeo.org
> > >
> > > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
>
> Message: 5
>
> Date: Thu, 14 Jan 2021 07:33:00 +0100
>
> From: xavier lhomme lhomme.xavier at gmail.com
>
> To: gdal-dev gdal-dev at lists.osgeo.org
>
> Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?
>
> Message-ID:
>
> CACqzBMzG=V7VTJT4Vd4dbY43Wh709eAkNoLzNcZg4YFc-dROhg at mail.gmail.com
>
> Content-Type: text/plain; charset="utf-8"
>
> Hello all
>
> The question of maintaining the old drivers raises a whole bunch of
>
> questions: how to finance the technical debt, how to involve more
>
> developers in this project, how to promote it, ... GDAL is an OSGeo
>
> project. Shouldn't these questions be addressed by OSGeo which should help
>
> in the distribution of funds, help in piloting this project...? Maybe OSGeo
>
> could get closer to an organization like OGC with members funding projects,
>
> initiative projets, testbed ...
>
> Best regards
>
> xlhomme
>
> Le jeu. 14 janv. 2021 ? 07:06, Ari Jolma ari.jolma at gmail.com a ?crit :
>
> > 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
> > > >
> > > > gdal-dev at lists.osgeo.org
> > > >
> > > > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> > 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/20210114/77e4653a/attachment.html
>
> Subject: Digest Footer
>
> gdal-dev mailing list
>
> gdal-dev at lists.osgeo.org
>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> ----------------------------------------------------------------------------------------------------
>
> End of gdal-dev Digest, Vol 200, Issue 29
More information about the gdal-dev
mailing list