[Proj] Migrate to github?
Howard Butler
howard at hobu.co
Sun Mar 15 22:11:47 PDT 2015
> On Mar 15, 2015, at 10:37 PM, Hermann Peifer <peifer at gmx.eu> wrote:
>
> On 2015-03-15 14:25, Charles Karney wrote:
>>
>> What I think is unacceptable is a 3-year interval between releases for
>> proj4. (4.8.0 was released on 2012-03-13; 4.9.0 was never released;
>> 4.9.1 was released on 2015-03-04.)
>>
>> Howard Butler stepped up after a long period of inactivity to make the
>> latest release of proj4 happen. I'm strongly inclined to defer to his
>> wishes going forward in the hope that we can see more timely releases.
>>
>
> I can only blow into the same horn: it hurted me seeing PROJ.4 moving
> towards abandonware, as e.g. confirmed by fact of release 4.9.0 being
> abandoned.
>
> From my somewhat simplistic use-PROJ.4-from-source perspective, the
> issue boils simply down to: "svn up" vs. "git pull". If I had to choose
> between abandoned code and bug reports in a politically correct
> repository vs. actively maintained code at github.com or similar: life
> is too short for not choosing the latter option.
>
> There is also:
> https://help.github.com/articles/support-for-subversion-clients/, for
> those who have a preference for: svn up.
Hmm, I didn't expect my proposal to move to github would be controversial. I know that Trac is a PITA, especially OSGeo's somewhat custom UserID implementation, and while going through the tickets it appeared to me that if it was easier to contribute, there would be more contribution. In my opinion, it is undeniable that github makes it much easier for people to contribute. I have seen this in projects I've managed, projects I've participated in, and projects I've contributed to.
All of the free github clones might have this property too, but then those things don't come with the built-in developer audience. And it's yet another thing to run and maintain for an organization like OSGeo that's already strapped for volunteer administration resources. I think it would be more efficient for OSGeo to pay for github infrastructure if they have to (don't need to currently) than to waste volunteer mojo on care and feeding of redundant and less-efficient self-hosting of infrastructure.
The Pull Request is an extremely powerful way to contribute that allows drive-by contribution. proj.4 is too important of a project to let fall away, but its nature means that only when people have issues will they be compelled to contribute. That cycle needs to be as friction free, painless and convenient as possible, otherwise it's just too damn much effort and people don't bother. If we want proj.4 to continue in low-maintenance mode, we need to make sure that drive-by contribution is front-and-center visible. Even if a contributor gets over the login hump, that type of contribution ends up being buried in Trac instead of in front of other potential contributors.
OSGeo's Trac instance is probably never going to get OAuth, meaning its logins and security access will always be kind of one-off. Trac itself is not so actively developed anymore. In combination, these facts mean OSGeo's Trac instance will slowly fall into disrepair like a crumbling city in which no one remembers why it was there in the first place. This is not because it has failed in any way, it is simply because people have moved on. It's the same thing for Google Code too. And someday in the future, the probability is not zero the same will happen to github too.
I think the market has clearly spoken with respect to DVCS like git vs central VCS like cvs/svn. CVS/SVN incentivizes very small contributions to the codebase if you are a developer external to the project. A geriatric project like proj.4 needs to make it easy for outside contributors to hop in and contribute without friction. Artificial barriers, purposeful or not, waste that developer attention.
A number of OSGeo projects use github for hosting, as do plenty of LocationTech ones as well. I'm comfortable using it for my projects (http://github.com/PDAL/PDAL) too. For a small audience, big impact project like proj.4, it's a well-matched venue.
Howard
More information about the Proj
mailing list