[SAC] Access to GDAL Trac database

[Harrison Grundy]

> 
> 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 

I think SAC can be a significant asset for the member projects by mitigating the risk in things like GitHub. If we were to develop an automated way to clone things like the projects' GH repos, issues, etc. it would allow the member projects to take advantage of these services, knowing that they cannot end up stuck in a dead end simply because someone else's business model didn't pan out.

One of the biggest things I've noticed with SAC that tends to consume a great deal of time is how much manual work is required to get from one point to another. From the time we have to spend making LDAP accounts, to managing our infrastructure on the various VM hosts... the vast majority of SAC's time is spent performing tasks that largely tread water. (strk, you're repeatedly saving our bacon with these, thanks!)

I think it's worth sitting down and figuring out which services can we offer to member projects that are difficult to handle themselves (Automated builds for various platforms comes to mind) but that don't require constant intervention by SAC to keep running.

At the same time, we need to take a close look at the services we're offering and figure out what needs to be done to reduce their administrative footprint. We don't do the member projects any good by overcommitting ourselves to things we don't have time to do well. (Something I'm incredibly guilty of myself.)

Let's set up a time to discuss this and what everyone sees SAC's role as being in the future, along with what we need to accomplish that.

Harrison