Live data from Hacker News

The single most important criteria when replacing GitHub

joeyh.name

101–110 of 135 posts

Re: The single most important criteria when replacing GitHub

#101

I’ve always thought of version control systems and issue trackers as separate products. GitHub just happens to implement them both in one place. As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. A far better solution would be to keep them decoupled, but easily pluggable and extendable. In fact, this is basically the status quo with any i…

> GitHub just happens to implement them both in one place.

Anyone who has version control and bug tracking under one roof in one company has them "in one place". Plenty of organizations have them integrated with some sort of common "dashboard", and multi-way navigation between tickets, commits and reviews.

Re: The single most important criteria when replacing GitHub

#102

I’ve always thought of version control systems and issue trackers as separate products. GitHub just happens to implement them both in one place. As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. A far better solution would be to keep them decoupled, but easily pluggable and extendable. In fact, this is basically the status quo with any i…

This also accurately describes what Microsoft purchased with LinkedIn. It still isn't the best platform in terms of what it covered but there's immense value in the community that was purchased. Because I see the pattern now, I'm curious what other communities will get folded into the MS ecosystem as a result in the future.

Skype was also a similar purchase. The pattern seems to be about dominant companies in the productivity/development space.

I wouldn't be surprised if companies like Atlassian, Slack, Jetbrains, Docker or Hashicorp are next.

Re: The single most important criteria when replacing GitHub

#103
post #80
post #65

People keep implying that Microsoft is somehow going to break git and somehow use it to destroy people who want to give away their code. You can just change your remotes and push to a different server. The protocol was designed to be distributed and prevent a single point of failure. Also, Microsoft and people who develop on Microsoft tools realise that there are network effects of being able to share code. This was…

> What they were after was Electron, since that's a very popular way of writing desktop applications currently. Would you mind explaining that? Microsoft doesn't need to purchase Electron for $7.5B of stock in order to write an Electron app. They already write Electron apps, one of which is used by many people who read HN.

Microsoft doesn't need to purchase Electron for $7.5B of stock in order to write an Electron app. They already write Electron apps, one of which is used by many people who read HN.

But not sure if they had control over Electron's future direction which they seem to clearly have atleast now.

V8 can also be replaced with Chakra in Electron i think.

In that light, GP might be right.

Re: The single most important criteria when replacing GitHub

#104

I’ve always thought of version control systems and issue trackers as separate products. GitHub just happens to implement them both in one place. As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. A far better solution would be to keep them decoupled, but easily pluggable and extendable. In fact, this is basically the status quo with any i…

I feel like the HN community fails repeatedly to really grok this concept. They focus on the negatives of having a single dominant player for a service (with worries about monopolistic practices and stagnation), but completely ignore WHY these single providers become dominant. There are HUGE network-effect benefits to having a single dominant provider. Right now, if I am looking for a code library, I pretty much only…

> WHY these single providers become dominant.

In this case, providing a free "let's pretend we're doing open source" play area to millions of people who can't code their way out of a wet paper bag,

Re: The single most important criteria when replacing GitHub

#105
post #55

Earlier quoted context omitted.

I feel like the HN community fails repeatedly to really grok this concept. They focus on the negatives of having a single dominant player for a service (with worries about monopolistic practices and stagnation), but completely ignore WHY these single providers become dominant. There are HUGE network-effect benefits to having a single dominant provider. Right now, if I am looking for a code library, I pretty much only…

I find that this network effect really makes me want to improve my projects, too. I've worked for hours on README files, making sure I had my licenses in check, and crafting the short repo description to be informative and useful for this reason [0]. If it's on GitHub, I feel like it needs to be presentation ready. Not everyone feels this way, but I do. If I just need a git repository, I store it locally. Git is a DV…

>If I just need a git repository, I store it locally. Git is a DVCS for a reason -- most single person projects don't need a remote anyway.

I use a remote as an easier-to-maintain-and-test backup than trying to maintain a mirrored local repository on another drive.

Re: The single most important criteria when replacing GitHub

#106
post #27

I’ve always thought of version control systems and issue trackers as separate products. GitHub just happens to implement them both in one place. As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. A far better solution would be to keep them decoupled, but easily pluggable and extendable. In fact, this is basically the status quo with any i…

> I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. But isn't it nice that you can say "issue X has been solved in commit Y"?

It feels like there might be two different uses of "coupling" here.

The linked article argues that GitHub locks in users by not storing everything in git, which what the post you're replying to is skeptical of. (I am, too.)

Being able to say "issue X has been solved in commit Y" is coupling the issue tracker and source control at a user experience level. The back end solutions are immaterial; they just need to be talking to one another, whether it's through plugins, or through proprietary features like GitHub already has (in which commits can be automatically linked to issues and vice-versa, merging PRs can automatically close issues, etc.).

Re: The single most important criteria when replacing GitHub

#108
post #80

Earlier quoted context omitted.

> What they were after was Electron, since that's a very popular way of writing desktop applications currently. Would you mind explaining that? Microsoft doesn't need to purchase Electron for $7.5B of stock in order to write an Electron app. They already write Electron apps, one of which is used by many people who read HN.

Microsoft doesn't need to purchase Electron for $7.5B of stock in order to write an Electron app. They already write Electron apps, one of which is used by many people who read HN. But not sure if they had control over Electron's future direction which they seem to clearly have atleast now. V8 can also be replaced with Chakra in Electron i think. In that light, GP might be right.

True. I'm not necessarily against that position. 100% of the purchase is scheduled to happen in stock, so this may not be a direct cost for MS, even for a benefit that shouldn't be valued anywhere near $7.5B in cash. There is nothing wrong with a win-win deal for everyone involved.

If this is a $7.5B purchase of Electron, my gut tells me that it isn't an arm's length transaction. I doubt that would happen in the US for Microsoft today, so I can't help but think there are other reasons than Electron for the purchase.

The announcement from MS didn't really spell out the reasons for the prospective purchase other than to support developers. When I see the filing for the purchase, there may be additional reasons listed in that.

Re: The single most important criteria when replacing GitHub

#109
post #45

Earlier quoted context omitted.

It works both ways. If you're too lazy to learn a service I chose to host my code, you don't deserve my code. (Sorry to put it harshly, but it's felt like we're all getting a bit spoiled. Especially compared to the old days.) For better or worse, you are the product if you use a centralized, free service. And the only thing keeping those dominant players dominant is the blind loyalty we seem to give freely. It's all…

I use (for example) 50 libraries, and want to submit bug reports and pull requests to all of them over the course of 5 years... and your attitude is "well.. if you don't make 50 accounts you don't deserve it!". Really? And also that's why we have package repositories... npm, nuget, PECL, composer, should i also register on 500 websites just so i can build a website or two? Also, github is free for open-source project…

> they do social good

Maybe, but maybe I disagree with how they treat their female employees, or maybe I don't like that they financially support some political thing or whatever.

Capitalism doesn't work without real competition. I shouldn't be obliged to do business with this one particular company if I want to develop Free Software. My point isn't that GitHub is evil; it's that each person should be free to decide that individually.

Re: The single most important criteria when replacing GitHub

#110

Earlier quoted context omitted.

I feel like the HN community fails repeatedly to really grok this concept. They focus on the negatives of having a single dominant player for a service (with worries about monopolistic practices and stagnation), but completely ignore WHY these single providers become dominant. There are HUGE network-effect benefits to having a single dominant provider. Right now, if I am looking for a code library, I pretty much only…

> WHY these single providers become dominant. In this case, providing a free "let's pretend we're doing open source" play area to millions of people who can't code their way out of a wet paper bag,

> can't code their way out of a wet paper bag

There was no lack of competent, original code on GitHub last time I checked... What are you referring to?

Post reply on HN