I regularly contribute to source bases hosted at github, bitbucket, and at a private gitlab installation. In my experience git is a incredible revolution in source code management and therefore in project management. I probably only use 5% of it, but that is enough for it to make a world of difference. The issue trackers in github, bitbucket and gitlab are also impressive tools. Gone are the days of suffering with things like bugzilla. The markdown documentation format is also quite a relief. It comes in really handy when you want to document things: installation guides, configuration manuals, APIs, and examples. Markdown is really great. We have definitely seen tremendous progress in the last five years.

Important tools are the ones that make a difference when collaborating with other people. A great tool must help managing the collaboration, because that is where the real gains and losses are made. In that respect, something like an IDE (such as Visual Studio) is totally irrelevant. It simply does not make a difference where it counts. Furthermore, something with lots of useless buttons can only be viewed as an unwelcome distraction.

One thing that worries me with Github is the centralization. When Github goes down[1], obviously a lot of repos suffer. For this reason alone I try not to depend on Github too much.

1: http://thenextweb.com/insider/2013/06/0 ... -affected/

The downfall of Sourceforge raises many important red flags about services alike. They hijacked GIMP[2] and bundled it with virii. Then they did the same thing to Nmap[3] and VLC[4].

2:
3: http://seclists.org/nmap-dev/2015/q2/194
4: https://blog.l0cal.com/2015/06/02/what- ... urceforge/

Unfortunately, perhaps due to Github, Sourceforge decided to do a CNet/download.com[5] out of desperation. Now we're calling for the death of Sourceforge and recommending Github to take its place[6].

5: http://insecure.org/news/download-com-fiasco.html
6: http://helb.github.io/goodbye-sourceforge/

I'm a big fan of Git. One thing that makes me itch is that Github drives users away from Git's decentralized nature towards: give us all your repos, we'll always be around, we promise! I can't help but wonder what will happen when Github loses market share, perhaps they will try pulling a CNet as well.

The centralization is a big risk. Although Git allows multiple upstreams, I think Github should support automatic sync with other remotes as goodwill. It would be very nice if they would add a way to set backup upstreams for any repo and give each repo its own subdomain. From there, they could simply create DNS entries for the subdomain, so when github.com repos become unreachable the client can fail over to the backup repos. E.g.:

192.30.252.130 repo.github.com
alt.upstream.domain repo.github.com

Git already supports push hooks, and writing a hook to push from repo.github.com to alt.upstream.domain when commits are pushed wouldn't take long. Of course, we could do this ourselves by pushing to our own repos which in turn have hooks for pushing to Github. Unfortunately, only with public key pairs with no passphrase.

BOFH wrote:One thing that worries me with Github is the centralization. When Github goes down[1], obviously a lot of repos suffer. For this reason alone I try not to depend on Github too much. The downfall of Sourceforge raises many important red flags about services alike. They hijacked GIMP[2] and bundled it with virii. Then they did the same thing to Nmap[3] and VLC[4]. The centralization is a big risk.

As you know from our experiences with bittorrent and bitcoin, centralization is technically the simple solution, while a peer-2-peer architecture is the complex one. When a serious attempt at decentralization finally works, it always constitutes a spectacular technical breakthrough. Given the dangers for censorship and other manipulations, I also want to see a functioning decentralized alternative for github.

This will probably not happen before github repos really get attacked, and it will only happen as a reaction to that. There is a serious problem of complacency in the field of internet security, causing inertia. That is why I am quite happy that they will beef up the existing policy of DNS domain confiscations for copyright infringement, and hopefully extend it to many other fields besides copyright infringement. Seriously, they should confiscate DNS names for the most flimsy reasons thinkable. I absolutely want to get rid of the DNS system. However, few people will do anything about setting up a decentralized DNS system, until they are finally forced to do so.

eriksank wrote:As you know from our experiences with bittorrent and bitcoin, centralization is technically the simple solution, while a peer-2-peer architecture is the complex one. When a serious attempt at decentralization finally works, it always constitutes a spectacular technical breakthrough. Given the dangers for censorship and other manipulations, I also want to see a functioning decentralized alternative for github.

Simple, yes, good, no. Decentralization was one of the original purposes of the civil Internet. It's sad seeing people turning on that principle out of greed.

eriksank wrote:This will probably not happen before github repos really get attacked, and it will only happen as a reaction to that. There is a serious problem of complacency in the field of internet security, causing inertia. That is why I am quite happy that they will beef up the existing policy of DNS domain confiscations for copyright infringement, and hopefully extend it to many other fields besides copyright infringement. Seriously, they should confiscate DNS names for the most flimsy reasons thinkable. I absolutely want to get rid of the DNS system. However, few people will do anything about setting up a decentralized DNS system, until they are finally forced to do so.

Clearnet has Dot-Bit[1], Tor's .onion is DHT and I imagine i2p does something similar. Clearly, there are already workable solutions to DNS censorship. Most of the world would probably find it adequate to use OpenDNS' DNSCrypt[2], which spawns a ::1:53 UDP listen daemon and proxies all requests to its upstream over SSL. Before you go on about the communist DNSCrypt party, allow me to include a list of public resolvers[3] and point out the fact that anyone can run their own :-)

1: https://bit.namecoin.info/
2: https://www.opendns.com/about/innovations/dnscrypt/
3: https://github.com/jedisct1/dnscrypt-pr ... olvers.csv

It's a bit of a shame that due to Kaminsky's fame, many sysadmins will find DNSSEC adequate without reading this (first) section of RFC3833:

Although the DNS Security Extensions (DNSSEC) have been under
development for most of the last decade, the IETF has never written
down the specific set of threats against which DNSSEC is designed to
protect. Among other drawbacks, this cart-before-the-horse situation
has made it difficult to determine whether DNSSEC meets its design
goals, since its design goals are not well specified. This note
attempts to document some of the known threats to the DNS, and, in
doing so, attempts to measure to what extent (if any) DNSSEC is a
useful tool in defending against these threats.