GitHub could be acquired by Microsoft

[Joakim]

On Thursday, 7 June 2018 at 19:02:31 UTC, Russel Winder wrote:
> On Thu, 2018-06-07 at 10:17 -0700, H. S. Teoh via 
> Digitalmars-d-announce wrote:
>> […]
>> 
>> Exactly!!!  Git was built precisely for decentralized, 
>> distributed development.  Anyone should be (and is, if they 
>> bothered to put just a tiny amount of effort into it) able to 
>> set up a git server and send the URL to prospective 
>> collaborators.  Anyone is free to clone the git repo and 
>> redistribute that clone to anyone else.  Anyone can create new 
>> commits in a local clone and send the URL to another 
>> collaborator who can pull the commits.  It should never have 
>> become the tool to build walled gardens that inhibit this free 
>> sharing of code.
>> 
>
> I think there is an interesting tension between using a DVCS as 
> a DVCS and no central resource, and thus no mainline version, 
> and using a DVCS in combination with a central resource.  In 
> the latter category the central resource may just be the 
> repository acting as the mainline, or, as with GitHub, GitLab, 
> Launchpad, the central resource provides sharing and reviewing 
> support.
>
> Very few organisations, except perhaps those that use Fossil, 
> actually use DVCS as a DVCS. Everyone seems to want a public 
> mainline version: the repository that represents the official 
> state of the project. It seems the world is not capable of 
> working with a DVCS system that does not even support 
> "eventually consistent". Perhaps because of lack of trying or 
> perhaps because the idea of the mainline version of a project 
> is important to projects.

Well, as Jonathan says, you have to release a build eventually, 
and you need a mainline version that you know has all the needed 
commits to release from.

If you have multiple people all releasing their own builds with 
each build getting a roughly equivalent number of downloads, then 
a mainline version may not be needed, but I know of no large 
project like that.

> In the past Gnome, Debian, GStreamer, and many others have had 
> a central mainline Git repository and everything was handled as 
> DVCS, with emailed patches. They tended not to support using 
> remotes and merges via that route, not entirely sure why. 
> GitHub and GitLab supported forking, issues, pull requests, and 
> CI. So many people have found this useful. Not just for having 
> ready made CI on PRs, but because there was a central place 
> that lots of projects were at, there was lots of serendipitous 
> contribution. Gnome, Debian, and GStreamer are moving to 
> private GitLab instances. It seems the use of a bare Git 
> repository is not as appealing to these projects as having the 
> support of a centralised system.

Nobody uses a DVCS alone, even the linux kernel guys have mailing 
lists and other software they use to coordinate with around git.

> I think that whilst there are many technical reasons for having 
> an element of process support at the mainline location 
> favouring the GitHubs and GitLabs of this Gitty world, a lot of 
> it is about the people and the social system: there is a sense 
> of belonging, a sense of accessibility, and being able to 
> contribute more easily.

There is some of that, but you could reproduce all of that in a 
technically decentralized manner.

> One of the aspects of the total DVCS is that it can exclude, it 
> is in itself a walled garden, you have to be in the clique to 
> even know the activity is happening.

Right now, yes, mailing lists and bugzilla can be forbidding to 
the noob, compared to just signing up on github and getting 
everything at one go. But as Basile's link above points out, 
there are tools like git-ssb that try decentralize all that:

http://git-ssb.celehner.com/%25RPKzL382v2fAia5HuDNHD5kkFdlP7bGvXQApSXqOBwc%3D.sha256

> All of this is not just technical, it is socio-technical.

It is all ultimately technical, but yes, social elements come 
into play.

One big thing that web software like github or trac helps with is 
reviewing pulls to the main repo. I'm not about to add dozens of 
remotes to my local repo to review pulls from all the 
contributors to dmd/druntime/phobos, the github pull review 
workflow is much easier than the git command-line equivalent.

However, it wouldn't be that hard to decentralize most of what 
github provides by coming up with a standard format to store 
issues and other discussion in a git repo, as I'm guessing 
git-ssb does. The only aspect that might present difficulty is 
that you may not get as nice a web viewer as github provided, as 
the built-in gitweb is not very good compared to github's web UI.

In that way, while many are complaining about using github, the 
OSS community doing so for all these years may have been optimal, 
in that as long as a money-losing company was willing to do that 
work for you for years, why not use it? Where was all that money 
being lost after all, if not on providing features to users who 
weren't paying enough to sustain it? Then, once you know whether 
github's business model works or not, apparently not, you 
consider moving elsewhere.

I don't know why some people are making a big deal about losing 
data with github, I can't imagine it'd be that hard to scrape. 
Gitlab has an exporter, you could simply repurpose that for your 
own uses. You may not get everything, like user permissions or 
some other internal controls, but you'd get everything that 
really matters.