7 ms·

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

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 issue tracker that has git integration (ability to tag issues in commits, etc.) If this was the only problem GitHub solved, then it would be competing with pivotal and the like. But issue tracking is not the only problem GitHub solves. The reason GitHub grew so large is because it created a community within a single space. It gave devs a place to collaborate on, and discover projects within an environment highly integrated with VCS and issue tracking. People don’t publish to GitHub for the issue tracker or repo hosting. Those are solved problems and many companies even use separate software for them. People publish to GitHub for the visibility, discoverability, and community. There is no technical solution that can usurp the advantages of GitHub as a social network, just like creating mastodon is not enough to kill twitter. The technology features of GitHub are easily substitutable. The community is not. Network effects are real, and they are the reason Microsoft felt confident paying $7.5bn for a platform that has no major technical differentiation from its competitors, but does have a huge and defensible moat around mindshare, due to its main value-add being rooted in network effects.

amelius 8y ago
> 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"?
- chatmasta 8y ago
  Yes it’s nice, and there are dozens of products that allow you to do that. My point is that this is not the main value-add of GitHub, and discussions of “replacing GitHub” that center around re-implementing these features are missing the point. The value-add of GitHub is its community and years of developer mindshare. There is no simple technical solution to replacing that.
  - shaded-enmity 8y ago
    You seem to focus on step 2, e.g. having community and mindshare, while completely ignoring why all the people got there in there in the first place and why it gained such momentum, the step 1.
    - chatmasta 8y ago
      Step 1 for a category defining product will never be the same as step 1 for a future competitor to that product. What worked for GitHub as step 1 will never work as step 1 for any service that replaces GitHub, because GitHub’s very existence changes the environment that allowed their step 1 to enable step 2. This is the luxury of first-mover advantage. GitHub only had to implement “good enough” features to attract a community. Any competitor that usurps GitHub will not only need to implement the right features, but also figure out how to move the community from GitHub to the new platform.
- RussianCow 8y ago
  You can do that without having the repo and the issue tracker in the same product. For example, at work we use Jira for issue management and GitHub for code, and with a Git Jira plugin, they integrate pretty seamlessly in both directions.
- sigjuice 8y ago
  That’s a matter of preference. A git repo will probably outlive fashionable-issue-tracker-of-the-day, so it might make sense to not embed this sort of information right inside git commits.
- chipotle_coyote 8y ago
  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.).
deleted 8y ago
[deleted]
cortesoft 8y ago
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 use the ones I find on github, even if the google search shows me projects hosted on other places. I want to be able to fork, clone, and contribute back without having to create accounts on other VCS sites. I don't want to learn another interface, or have to remember which site had which project. I want to be able to have a single list of 'starred' projects that I am following. I want to only have to learn one system and check in one place. No matter what, that is just easier as a user. I know there are costs, but those really have to outweigh the benefits to make it worthwhile having multiple providers. I have yet to see a federated system that solves these problems, and the fact that no federated system is as popular as the centralized systems lead me to believe it might be an unsolvable problem.
- shawn 8y ago
  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 about that convenience! I get that. But morals have their place, and in the coming months the world will show whether they care at all about centralization. It's probably important to stay nervous about centralization. If we let our guards down, we could find ourselves on the short end of an upsetting stick. History has shown time and again that when companies have no incentive to compete, they tend not to try. The reason Facebook can be so free with your data is that there is no way to compete with them. With github, at least there's a way. Honestly, the biggest thing holding back Github competitors is that they won't just make their service look identical to Github. Gitlab looks strange every time I run across a repo. Instead everyone wants to be different, and usually it's not better.
  - 8y ago
w0rd-driven 8y ago
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.
- alien_ 8y ago
  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.
snowwolf 8y ago
Exactly this. I can discover and contribute to many projects (creating issues, submitting pull requests, with discussion) without having to learn 100s of subtly different UX each “distributed” system chooses to implement it. And I know most other developers can also contribute to my projects in a familiar way.
rmsaksida 8y ago
Exactly. But an OSS community is very different from Twitter or Instagram. People will migrate to another website if Microsoft screws this up. Even if they don't screw it up, a lot of people are already willing to move because they hold grudges or are against a company like Microsoft owning the space. If a GitLab or Gitea-backed community surfaces managed by a foundation, GitHub will be vulnerable. Right now there isn't much of a point in moving to GitLab.com because they could be acquired as well.
verigit 8y ago
If you are only interested in the version control part and you are a Mac user, you can give EasyGit (https://easygit.me https://easygit.me) a try. It stores your repos privately on iCloud and it doesn't use any 3rd party servers or analytics. In fact its sandbox doesn't allow any outgoing network connections, apart from talking to iCloud. Disclaimer: This is my app and btw I'm running a WWDC promotion and you can download it for free till Friday: https://itunes.apple.com/us/app/easygit/id1228242832?mt=12 https://itunes.apple.com/us/app/easygit/id1228242832?mt=12
kodablah 8y ago
> I’ve always thought of version control systems and issue trackers as separate products. Agreed, but coupling has extreme benefits. No matter how stringent you are on your commit message requirements, you'll never capture the scope of a code change as well as the originating issue. They may be separate products, but the need for a cross-vendor common interface/implementation persists. Also, the ability to take your ball and play elsewhere is required too. If a git-like approach were taken towards issue management and all of these platforms could implement/use it, nobody would ask to piggy back on git. Then again, you can apply this same discussion to any form of structured, persisted digital content...nobody wants to be locked in. Just so happens that the code part happens to have an unencumbered implementation that others have embraced.
jancsika 8y ago
> As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. What do you mean by coupling? Are you talking about what Gitlab Omnibus does by bundling an issue tracker and other web services along with its core git functionality? If so, you're wrong-- Gitlab's approach helps a busy maintainer get their work done without being hemmed in to a service like Github. The issue tracker's defaults are sane, non-technical users can easily sign up using the other bundled services and communicate using it, and it gets upgraded as a side-effect of upgrading Gitlab itself. If I had instead used one of your claimed "far better solutions," I'd have spent hours researching issue trackers and installing/configuring one of them. That's time taken away from developing the software I'm housing in Gitlab. Or, even worse, I'd have asked on the dev list, "what's a good, solied open source issue tracker?" And we'd have bike-shedded for 10x the time.
kazinator 8y ago
> 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.

amelius 8y ago

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

chatmasta 8y ago
Yes it’s nice, and there are dozens of products that allow you to do that. My point is that this is not the main value-add of GitHub, and discussions of “replacing GitHub” that center around re-implementing these features are missing the point. The value-add of GitHub is its community and years of developer mindshare. There is no simple technical solution to replacing that.
- shaded-enmity 8y ago
  You seem to focus on step 2, e.g. having community and mindshare, while completely ignoring why all the people got there in there in the first place and why it gained such momentum, the step 1.
  - chatmasta 8y ago
    Step 1 for a category defining product will never be the same as step 1 for a future competitor to that product. What worked for GitHub as step 1 will never work as step 1 for any service that replaces GitHub, because GitHub’s very existence changes the environment that allowed their step 1 to enable step 2. This is the luxury of first-mover advantage. GitHub only had to implement “good enough” features to attract a community. Any competitor that usurps GitHub will not only need to implement the right features, but also figure out how to move the community from GitHub to the new platform.
RussianCow 8y ago
You can do that without having the repo and the issue tracker in the same product. For example, at work we use Jira for issue management and GitHub for code, and with a Git Jira plugin, they integrate pretty seamlessly in both directions.
sigjuice 8y ago
That’s a matter of preference. A git repo will probably outlive fashionable-issue-tracker-of-the-day, so it might make sense to not embed this sort of information right inside git commits.
chipotle_coyote 8y ago
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.).

deleted 8y ago

[deleted]

cortesoft 8y ago

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 use the ones I find on github, even if the google search shows me projects hosted on other places. I want to be able to fork, clone, and contribute back without having to create accounts on other VCS sites. I don't want to learn another interface, or have to remember which site had which project. I want to be able to have a single list of 'starred' projects that I am following. I want to only have to learn one system and check in one place. No matter what, that is just easier as a user. I know there are costs, but those really have to outweigh the benefits to make it worthwhile having multiple providers. I have yet to see a federated system that solves these problems, and the fact that no federated system is as popular as the centralized systems lead me to believe it might be an unsolvable problem.

shawn 8y ago
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 about that convenience! I get that. But morals have their place, and in the coming months the world will show whether they care at all about centralization. It's probably important to stay nervous about centralization. If we let our guards down, we could find ourselves on the short end of an upsetting stick. History has shown time and again that when companies have no incentive to compete, they tend not to try. The reason Facebook can be so free with your data is that there is no way to compete with them. With github, at least there's a way. Honestly, the biggest thing holding back Github competitors is that they won't just make their service look identical to Github. Gitlab looks strange every time I run across a repo. Instead everyone wants to be different, and usually it's not better.
- 8y ago

w0rd-driven 8y ago

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.

alien_ 8y ago
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.

snowwolf 8y ago

Exactly this. I can discover and contribute to many projects (creating issues, submitting pull requests, with discussion) without having to learn 100s of subtly different UX each “distributed” system chooses to implement it. And I know most other developers can also contribute to my projects in a familiar way.

rmsaksida 8y ago

Exactly. But an OSS community is very different from Twitter or Instagram. People will migrate to another website if Microsoft screws this up. Even if they don't screw it up, a lot of people are already willing to move because they hold grudges or are against a company like Microsoft owning the space. If a GitLab or Gitea-backed community surfaces managed by a foundation, GitHub will be vulnerable. Right now there isn't much of a point in moving to GitLab.com because they could be acquired as well.

verigit 8y ago

If you are only interested in the version control part and you are a Mac user, you can give EasyGit (https://easygit.me https://easygit.me) a try. It stores your repos privately on iCloud and it doesn't use any 3rd party servers or analytics. In fact its sandbox doesn't allow any outgoing network connections, apart from talking to iCloud. Disclaimer: This is my app and btw I'm running a WWDC promotion and you can download it for free till Friday: https://itunes.apple.com/us/app/easygit/id1228242832?mt=12 https://itunes.apple.com/us/app/easygit/id1228242832?mt=12

kodablah 8y ago

> I’ve always thought of version control systems and issue trackers as separate products. Agreed, but coupling has extreme benefits. No matter how stringent you are on your commit message requirements, you'll never capture the scope of a code change as well as the originating issue. They may be separate products, but the need for a cross-vendor common interface/implementation persists. Also, the ability to take your ball and play elsewhere is required too. If a git-like approach were taken towards issue management and all of these platforms could implement/use it, nobody would ask to piggy back on git. Then again, you can apply this same discussion to any form of structured, persisted digital content...nobody wants to be locked in. Just so happens that the code part happens to have an unencumbered implementation that others have embraced.

jancsika 8y ago

> As others are alluding to in the comments, I’m highly skeptical of coupling the issue tracker and other non-VCS features with git. What do you mean by coupling? Are you talking about what Gitlab Omnibus does by bundling an issue tracker and other web services along with its core git functionality? If so, you're wrong-- Gitlab's approach helps a busy maintainer get their work done without being hemmed in to a service like Github. The issue tracker's defaults are sane, non-technical users can easily sign up using the other bundled services and communicate using it, and it gets upgraded as a side-effect of upgrading Gitlab itself. If I had instead used one of your claimed "far better solutions," I'd have spent hours researching issue trackers and installing/configuring one of them. That's time taken away from developing the software I'm housing in Gitlab. Or, even worse, I'd have asked on the dev list, "what's a good, solied open source issue tracker?" And we'd have bike-shedded for 10x the time.

kazinator 8y ago

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