[SAC] Access to GDAL Trac database

[Howard Butler]

> On Sep 25, 2017, at 3:28 AM, Regina Obe <lr at pcorp.us> wrote:
> 
> If Even and rest of GDAL are willing to try gitea/gogs, I'd be willing to do the work of the port.
>  
>                 Sandro has already done a proof of concept.  I would like to see this work.
>  
>                 I think what we have at stake here is something bigger than GDAL moving.
>                 It's our trust in the very foundation of SAC and to a larger extent OSGeo  and it's usefulness to help with infrastructure support and manage that support.

Ten years ago when OSGeo forming, support from SAC was a differentiator to member projects. Projects needed infrastructure and the cost to maintaining that yourself was quite high. Infrastructure cost is now cheap (free beer!) and SAC as a differentiator is diminished. 

In fact, SAC-supported infrastructure now often lag what projects can individually acquire for free due to volunteer resources being limited, etc. The challenges that SAC has as a volunteer endeavor are not unique. PyPI from Python, for example, suffers from a lack of volunteers willing to sign up for pager duty for no pay.

Projects that choose GitHub are not merely doing so in relation to feature-for-feature comparisons to control-your-own-fate Free (tm) solutions. They're doing so because of the network effects of GitHub are now so strong that doing your own thing has a significant opportunity cost. 

Take for example the OSGeo login. The barrier to getting that is now so high that one-time casual contribution to a low frequency project is simply not done. One can argue it's necessary too, given the manpower realities of the OSGeo organization. Outsourcing that problem to specialists like GitHub means that spammers and DoS and all that other operational reality of running a service like that is shared and the cost is hidden. 

>                 I'd like to help in restoring that trust.  We've got things like maling lists, OSGeo support, and project websites that need a strong SAC.  Also tons I'd like to see that could be possible with a stronger SAC.

OSGeo should collect resources and pay specialists to provide needed services to member projects who cannot afford it themselves. When the inevitable day that GitHub goes non-Free (beer), that could mean OSGeo paying those costs. Right now, OSGeo endeavors to be specialists themselves, but it does not have the manpower to sustain them indefinitely on a volunteer basis. Each new crisis prompts a renewal of contribution, but it lasts and dithers until the next crisis kicks off the cycle again. 

I think I've migrated GDAL through two generations of project infrastructure (CVS/Bugzilla, Trac/SVN). In my opinion, the continuity of historical artifacts being available on-demand online (instead of in an archive for someone to dig around) is not as important as the convenience and velocity in which the infrastructure enables contribution. Trac/SVN was more convenient and easier to use than self-hosted CVS/Bugzilla. A self-hosted GitHub clone could have feature parity, but it will still be missing key important elements due to GitHub's network effects. If we value enabling the easiest and the most contribution possible, we should ask whether or not rolling our own actually achieves those goals. 

Some OSGeo members value free software ideals, and their projects' infrastructure reflects them. Not every OSGeo project needs live those ideals, and it should be up to each project to chose what works best for it.

Howard