12 ms·

The single most important criteria when replacing GitHub

211 points by edward 8y ago

tschellenbach 8y ago
I'm perfectly happy with Github. They have a very clear value proposition which they offer at a price point which is only a tiny percentage of the value they create. Great company that has empowered accelerated software innovation across the world. Not sure what's up with this whole company X makes money so must be evil vibe. Most of the people complaining about this have well paid jobs so there's a bit of hypocrisy going on here.
- hueving 8y ago
  Nobody cares that they make money. They care about it not being open source or having easy-to-migrate data (lock-in).
  - throwaway28921 8y ago
    Strange that people are only caring that it's closed source and locked in after MS bought them.
devy 8y ago
Don't forget GitHub, Microsoft and et al, co-wrote and contribute to libgit2[1], a portable pure-C Git core implementation that's aim for cross platform compatibility. As the author noted himself, GitHub keeps, source code, user pages/wikis and gists in Git. Other objects like issues, repo relationships, accounts, project details in their own database[2]. To me, that's a fairly standard way of storing data if I were to develop a GitHub system. Even rate limits for APIs are common way of protecting them from API abuse. Why is all of sudden Joey has criticism? [1]: https://libgit2.github.com/ https://libgit2.github.com/ [2]: http://joeyh.name/blog/entry/a_Github_survey/ http://joeyh.name/blog/entry/a_Github_survey/
- servilio 8y ago
  Did you read your second link to Joey's post from 6 years ago? After reading that myself I don't see the criticism as "all of sudden".
nwah1 8y ago
This reminds me Fossil SCM. The bug tracking and wiki are part of the distributed version control system. https://en.wikipedia.org/wiki/Fossil_(software) https://en.wikipedia.org/wiki/Fossil_(software)
- DC-3 8y ago
  Fossil is great software and it's worth mentioning that it's written by the creator of SQLite. I'm using it to version-control my dotfiles and it works nicely.
- bobcallme 8y ago
  I used it for a while and it was great. Sadly too many people refused to use it because "...it's not git!" :(
- gowld 8y ago
  https://en.wikipedia.org/wiki/Trac https://en.wikipedia.org/wiki/Trac has that functionality but integrates with popular VCSes instead of rolling its own.
  - bachmeier 8y ago
    A bit of trivia: The creator of Fossil also created cvstrac, which later turned into trac. A further bit of trivia: Fossil and Git were developed at the same time. You could argue that Linus should have used Fossil rather than rolling his own. Fossil was built for the workflow of the sqlite developers, who do not believe Git is a good fit, and they make it available to others.
- DrBazza 8y ago
  Came here to say exactly this.
- philwelch 8y ago
  I had a job once where we used Lotus Notes. I'll take extensibility over integration any day.
jcadam 8y ago
One would think setting up a non-profit organization (a la Wikipedia) to host a Github-like service for open source projects would be a good idea (I'd work on such a project). But without capital to expend on marketing/outreach, I'm not sure such a thing would gain much traction.
- awll 8y ago
  I think https://notabug.org/about https://notabug.org/about fits your criteria.
- gowld 8y ago
  Why is a nonprofit better than a commercial vendor? It's still subject to the whims of the leadership. It's especially ironic with Git, which has portability as a core feature, so hosting can be on as many hosts as possible, and it's simple to move the "master" as desired.
- amelius 8y ago
  Why exactly would a source control system need traction? It's just a place where you store your git repo. And as for discoverability: I wouldn't want to give a single party control over that, actually. I'd say let people discover projects through other means, such as HN.
  - ghettoimp 8y ago
    > It's just a place where you store your git repo. But Github is so much more than that. It's a public forum to discuss and prioritize issues, a social network to start projects with friends, an automatic portfolio of sorts for your resume, and a really well managed, nicely integrated, reliable service. This is all, I think, a function of its scale and the traction it's gotten.
    - amelius 8y ago
      Still doesn't explain why projects should be all in one place, as opposed to spread over the internet.
thinkingkong 8y ago
But the wikis are in git and you can contribute to them that way if you want to. The rest have no real business being in git. There are other interfaces for getting your data out if you really need it. So much of this argument is just “this one format is better than X” without any tradeoffs being mentioned.
nartz 8y ago
Interesting thought exercise, but must disagree - git is VERY FAR from a database replacement (especially at scale). Maybe some git-like interface on top of a database is more what you want...
- joeyh 8y ago
  Single git repositories do not need to scale to a million issues or comments. It've used git as a database very productively, at well beyond that scale. https://joeyh.name/blog/entry/databranches/ https://joeyh.name/blog/entry/databranches/
  - gowld 8y ago
    that says > NOSQL database which is an important limitation.
    - icebraining 8y ago
      Why is it an important limitation in this case?
Senderman 8y ago
Criterion.
- rdiddly 8y ago
  No kidding huh. He's doubling down on "criteria" though. Gets all butthurt when somebody politely tries to point it out. Cites "common usage," which is for commoners, chortle chortle, and doesn't make it right.
- bahjoite 8y ago
  "And this kind of pedantry feels like a tactic." Astonishing that this was the response to a comment which offered-up le mot juste.
RyanCavanaugh 8y ago
This seems like a conflation. Your repo issues could be stored in a SQLite database, or a flat list of JSON files, or a git repo, or a giant text file, any of which your host might or might not give you direct access to. The thing to consider (if portability is your primary concern) isn't the underlying storage format, it's whether or not you have a straightforward way to move it between providers.
- mkirklions 8y ago
  I didnt understand why this mattered either. One is storage of data that can be downloaded whenever, the other is basically a comment field.
- crossman 8y ago
  Couldn't agree more. It seems naive to think that source control would be a good system for the kind of operations performed in issue tracking
  - icebraining 8y ago
    Issue tracking is all about managing changes to objects (issues) made over time by multiple people from different machines. Seems like a perfect case for VCS to me.
    - yrashk 8y ago
      I thought so, too and developed SIT (https://sit.fyi https://sit.fyi). An interesting thought that I had initially helped me make it even more future-proof: Git is likely not here forever, it'll probably get replaced with something else in due time. So I designed SIT to be both merge-conflict-free and SCM-independent by relying just on additive sets of files.
    - Skunkleton 8y ago
      A VCS might be a good storage location for these 'objects', but it certainly doesn't provide the structure to manage them.
jnbiche 8y ago
While I'm sympathetic to the mindset behind this post (ie, by wary of git centralization), I think that (for example) issue storage is an orthogonal issue from issue format. With a standardized issue format, it could be stored in a database or git, and as long as the service had an open export function, it would require no lock-in. Also, as some have pointed out here, storing highly relational data like issues and connected profiles, etc, could be an exercise in frustration if you tried to store all that in git. At the very least, it would be limiting.
- numbsafari 8y ago
  Agreed. This reminds me of people in the healthcare space who advocate for blockchain as some magical way of resolving integration issues. The absence of a robust, well adopted and supported format, is the greater reason for integration issues. Changing the storage and distribution format might bring certain benefits, but it doesn’t solve the core problem.
sytse 8y ago
Storing things like issues in git is possible. But it makes it harder to make functionality on top like upvotes and issue boards. Not impossible for sure but it slows down development. And it would only help with portably if rate limits are the problem. So far GitHub rate limits for logged in users are decent, we migrated 200k projects in 48 hours. Even when you store issues in repos the format would likely differ between different tools. If the format differs it is just as easy to write an importer that uses the API.
sametmax 8y ago
Even if I ended up migrating from github, I would still look for a centralized instance. Why ? The price for one migration in a few years is not a big deal compare to self hosting, which is a human resource hog for small entities. I have more important things to do than to deal with deploy, configure, maintain, document, secure, and test my own instance. I really don't want to admin one more server just for that. I don't want to play cat and mouse with spiders, brute forcers or DDOS events. And I do want a huge visibility and community around the tool I use. And my users may not want to create yet another account to open a bug ticket.
- Walkman 8y ago
  I feel like everybody is overestimating the cost of self hosting. I run my own instance of GitLab, but the "costly" part was setting it up and making backups. Since then I just "apt-get upgrade" and there is a new version and that's it. Since I set it up, I haven't touched any of the configuration files. The availability guarantees are much easier to keep for a small team than for thousands, so you don't really have to worry about that either.
  - themacguffinman 8y ago
    You're ignoring the cost for community projects where the community now needs to invest in learning and using your own self-hosted repo, which may or may not have a good UX. This is a barrier to entry.
    - Walkman 8y ago
      I agree with this, but the cost is centralization and single point of failure.
      - sametmax 8y ago
        Sure. No free lunch. It's just important to understand the nature and size of the costs, so that you can make the trade off adapted to your context.
komali2 8y ago
This site on mobile lol, how did this even happen: https://i.imgur.com/4AbIEuz.png https://i.imgur.com/4AbIEuz.png
- jkaplowitz 8y ago
  Looks fine on my Google Pixel (Chrome, Android 8.1). But yeah the site's rendering on your phone seems broken indeed.
- fredsted 8y ago
  For some reason there's a height property on the nav bar, which prevents it from expanding when the browser is wrapping. When removed it looks fine.
dschep 8y ago
There exist multiple solutions that store issues in git: * https://github.com/duplys/git-issues https://github.com/duplys/git-issues * https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue
chatmasta 8y ago
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.
neilk 8y ago
When you couple services together, you decrease the potential user base. For example, Github issues are underpowered for many people. But at least you can ignore them and use your own service. Many source control systems tried to offer all-in-one platforms but it’s never worked so far. In fact, we don’t even do PRs the way the authors of git intended. For integrations, it might be better to settle on a configuration file format and maybe some conventions. Maybe that could be checked into your repo. But then you need fine-grained control over who can modify that, and encryption to keep passwords secret, and those aren’t standard features of source control either. Maybe we could come up with conventions that were great for hobbyists and the enterprise. But open source communities and standards committees are really bad at that, compared to just leaving it the marketplace.
- twblalock 8y ago
  Plus, even if Git did have all of the features people want today, people will continue to think of new features that are not supported by Git and need to be implemented outside of it.
vsviridov 8y ago
https://sit.fyi/ https://sit.fyi/ allows you to keep your issues in the github repo itself. It's written by https://news.ycombinator.com/user?id=yrashk https://news.ycombinator.com/user?id=yrashk
Rjevski 8y ago
If anyone has a good idea for a format/protocol to store issues & pull requests in Git itself, I'm all ears. There is a reason why every single product uses a separate database for those.
- yrashk 8y ago
  I've worked on this in SIT project (https://sit.fyi https://sit.fyi). While the core is generalized, the very first module available for it is issue tracking and I've been using it for a few months now. It enabled some scenarios previously difficult/impossible to achieve -- for example, merge requests can contain updates to issues as well, allowing one to make non-trivial updates to issues once their patch is merged in (for example, open a dozen of new issues [todo list for improving the new feature], leave comments, etc.)
- jwilk 8y ago
  Separate (orphan) branch, which contains one markdown file for each issue/PR. If you figure out how to encode comment metadata and other pesky stuff like PR reviews, this should be both human and machine-readable.
BillinghamJ 8y ago
This isn't entirely true. GitHub's wikis and the gist system are both backed by git - because it makes sense for those. It wouldn't make so much sense for issues, pull requests, etc. If they were backed that way, they'd very likely be rather slow to query (as GitHub doesn't keep the latest data in a "checked out" state). Not to mention the fact that you can just ask them for a data export and they'll provide it all to you happily in JSON format. This post doesn't really have much reality backing its criticisms.
- jelder 8y ago
  Came here to say this. That wikis and gist are backed by git is very useful. Trying to wedge issues etc into a git model would be an engineering disaster; these are clearly problems best solved with a database. There may be valid criticisms about MS GitHub, but this isn't one of them.
Boulth 8y ago
Git appraise stores PR data in git repository: https://github.com/google/git-appraise https://github.com/google/git-appraise
danmg 8y ago
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 just a side benefit and not altruism. What they were after was Electron, since that's a very popular way of writing desktop applications currently.
- IncRnd 8y ago
  > 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.
  - stealthmodeclan 8y ago
    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.
    - IncRnd 8y ago
      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.
trexen 8y ago
"out of the trap we now find ourselves in." The anti Microsoft panic about GitHub feels childish and pedantic. Perhaps if there was some evidence post acquisition of Microsoft trying to do unpalatable things then there might be room to complain. But just to knee jerk advocate leaving GitHub because you are a Microsoft hater lacks credibility and comes across as whining and silly.
- PretzelFisch 8y ago
  I don't know how these groups have the time to worry about what-ifs. It's better to just play wait and see. Does MS make GitHub worse, does Google buy a git provider to compete. To many questions to take action right now.
MrBurrito 8y ago
If you are in the EU, you have the right to take the data with you. Thanks, GDPR. https://ec.europa.eu/info/law/law-topic/data-protection/reform/rights-citizens/my-rights/what-are-my-rights_en https://ec.europa.eu/info/law/law-topic/data-protection/refo...
smg 8y ago
Yet another way to store issues in the git repo https://gitlab.com/monnier/bugit/ https://gitlab.com/monnier/bugit/ This one is by Stefan Monnier (former emacs lead developer)
mikece 8y ago
The idea of including wiki and issue tracking as part of the repo is a great idea to include in my OpenVersionControl spec idea -- https://news.ycombinator.com/item?id=17242015 https://news.ycombinator.com/item?id=17242015 Of course Fossil has exactly what you're suggesting.
EGreg 8y ago
What happened to this: https://keybase.io/blog/keybase-chat https://keybase.io/blog/keybase-chat Encrypted github support!
KaiserPro 8y ago
The massive rush to migrate from github is childish at best. To put that in context, I lived through MS's various attempts to kill off competitors (Yes, I paid for netscape.) I've worked with LDAP/kerberos and cursed the weird schema changes that are AD. But that was > 15 years ago. I'd gladly pay for AD, even more if its a linux based infra. (Hmmmmm kerberos) Github was loosing cash, had a toxic culture (Abuse of power, side effects of sexism, and then hiring people for being agitators instead of coders.) Microsoft has the money, time and power to improve the product, fire the arseholes and make sure that github is in some sort of shape in the long run. Just look at the alternatives: atlassian, or worse still oracle/IBM. So sure, migrate to gitlab, Its a good product, when its working. Github has many faults, but reliability isn't one of them.
deleted 8y ago
[deleted]
parvenu74 8y ago
So is the main complaint that GitHub is a closed-source, proprietary product? Or is it that they don't provide you with an "export all of my code, issues, wiki, conversations, social graph, etc to GitLab" button?
- servilio 8y ago
  The criteria he proposes is about your second point: an easy way to ensure you are able to export all the data that you can later import somewhere else. The second part of this is as important as the former, a pretty "Export" button is useless if the data can't be used later to replicate your project somewhere else. The opening paragraph is also very on point about the negative effects of Github on the Git ecosystem.
marcinkuzminski 8y ago
I don't agree with the author here. Over the years i read about using VCS to store underlying data, so it's all shared, and you keep the data. Reality is that building a complex source code management platform is not easy. Storing things inside GIT repo and not database would be a huge performance issue when we're talking about scaling such system. If you have 1 repo yeah, it's doable and easy, but if you're talking 100 000 projects that's another story. This problem keeps returning onto HN again, and again. I think this simply wouldn't work for mentioned reason, and few others that come to my mind. And i know a bit about building a source code management platform because I built RhodeCode.

211 points by edward 8y ago

I'm perfectly happy with Github. They have a very clear value proposition which they offer at a price point which is only a tiny percentage of the value they create. Great company that has empowered accelerated software innovation across the world. Not sure what's up with this whole company X makes money so must be evil vibe. Most of the people complaining about this have well paid jobs so there's a bit of hypocrisy going on here.

hueving 8y ago
Nobody cares that they make money. They care about it not being open source or having easy-to-migrate data (lock-in).
- throwaway28921 8y ago
  Strange that people are only caring that it's closed source and locked in after MS bought them.

devy 8y ago

Don't forget GitHub, Microsoft and et al, co-wrote and contribute to libgit2[1], a portable pure-C Git core implementation that's aim for cross platform compatibility. As the author noted himself, GitHub keeps, source code, user pages/wikis and gists in Git. Other objects like issues, repo relationships, accounts, project details in their own database[2]. To me, that's a fairly standard way of storing data if I were to develop a GitHub system. Even rate limits for APIs are common way of protecting them from API abuse. Why is all of sudden Joey has criticism? [1]: https://libgit2.github.com/ https://libgit2.github.com/ [2]: http://joeyh.name/blog/entry/a_Github_survey/ http://joeyh.name/blog/entry/a_Github_survey/

servilio 8y ago
Did you read your second link to Joey's post from 6 years ago? After reading that myself I don't see the criticism as "all of sudden".

nwah1 8y ago

This reminds me Fossil SCM. The bug tracking and wiki are part of the distributed version control system. https://en.wikipedia.org/wiki/Fossil_(software) https://en.wikipedia.org/wiki/Fossil_(software)

DC-3 8y ago
Fossil is great software and it's worth mentioning that it's written by the creator of SQLite. I'm using it to version-control my dotfiles and it works nicely.
bobcallme 8y ago
I used it for a while and it was great. Sadly too many people refused to use it because "...it's not git!" :(
gowld 8y ago
https://en.wikipedia.org/wiki/Trac https://en.wikipedia.org/wiki/Trac has that functionality but integrates with popular VCSes instead of rolling its own.
- bachmeier 8y ago
  A bit of trivia: The creator of Fossil also created cvstrac, which later turned into trac. A further bit of trivia: Fossil and Git were developed at the same time. You could argue that Linus should have used Fossil rather than rolling his own. Fossil was built for the workflow of the sqlite developers, who do not believe Git is a good fit, and they make it available to others.
DrBazza 8y ago
Came here to say exactly this.
philwelch 8y ago
I had a job once where we used Lotus Notes. I'll take extensibility over integration any day.

jcadam 8y ago

One would think setting up a non-profit organization (a la Wikipedia) to host a Github-like service for open source projects would be a good idea (I'd work on such a project). But without capital to expend on marketing/outreach, I'm not sure such a thing would gain much traction.

awll 8y ago
I think https://notabug.org/about https://notabug.org/about fits your criteria.
gowld 8y ago
Why is a nonprofit better than a commercial vendor? It's still subject to the whims of the leadership. It's especially ironic with Git, which has portability as a core feature, so hosting can be on as many hosts as possible, and it's simple to move the "master" as desired.
amelius 8y ago
Why exactly would a source control system need traction? It's just a place where you store your git repo. And as for discoverability: I wouldn't want to give a single party control over that, actually. I'd say let people discover projects through other means, such as HN.
- ghettoimp 8y ago
  > It's just a place where you store your git repo. But Github is so much more than that. It's a public forum to discuss and prioritize issues, a social network to start projects with friends, an automatic portfolio of sorts for your resume, and a really well managed, nicely integrated, reliable service. This is all, I think, a function of its scale and the traction it's gotten.
  - amelius 8y ago
    Still doesn't explain why projects should be all in one place, as opposed to spread over the internet.

thinkingkong 8y ago

But the wikis are in git and you can contribute to them that way if you want to. The rest have no real business being in git. There are other interfaces for getting your data out if you really need it. So much of this argument is just “this one format is better than X” without any tradeoffs being mentioned.

nartz 8y ago

Interesting thought exercise, but must disagree - git is VERY FAR from a database replacement (especially at scale). Maybe some git-like interface on top of a database is more what you want...

joeyh 8y ago
Single git repositories do not need to scale to a million issues or comments. It've used git as a database very productively, at well beyond that scale. https://joeyh.name/blog/entry/databranches/ https://joeyh.name/blog/entry/databranches/
- gowld 8y ago
  that says > NOSQL database which is an important limitation.
  - icebraining 8y ago
    Why is it an important limitation in this case?

Senderman 8y ago

Criterion.

rdiddly 8y ago
No kidding huh. He's doubling down on "criteria" though. Gets all butthurt when somebody politely tries to point it out. Cites "common usage," which is for commoners, chortle chortle, and doesn't make it right.
bahjoite 8y ago
"And this kind of pedantry feels like a tactic." Astonishing that this was the response to a comment which offered-up le mot juste.

RyanCavanaugh 8y ago

This seems like a conflation. Your repo issues could be stored in a SQLite database, or a flat list of JSON files, or a git repo, or a giant text file, any of which your host might or might not give you direct access to. The thing to consider (if portability is your primary concern) isn't the underlying storage format, it's whether or not you have a straightforward way to move it between providers.

mkirklions 8y ago
I didnt understand why this mattered either. One is storage of data that can be downloaded whenever, the other is basically a comment field.
crossman 8y ago
Couldn't agree more. It seems naive to think that source control would be a good system for the kind of operations performed in issue tracking
- icebraining 8y ago
  Issue tracking is all about managing changes to objects (issues) made over time by multiple people from different machines. Seems like a perfect case for VCS to me.
  - yrashk 8y ago
    I thought so, too and developed SIT (https://sit.fyi https://sit.fyi). An interesting thought that I had initially helped me make it even more future-proof: Git is likely not here forever, it'll probably get replaced with something else in due time. So I designed SIT to be both merge-conflict-free and SCM-independent by relying just on additive sets of files.
  - Skunkleton 8y ago
    A VCS might be a good storage location for these 'objects', but it certainly doesn't provide the structure to manage them.

jnbiche 8y ago

While I'm sympathetic to the mindset behind this post (ie, by wary of git centralization), I think that (for example) issue storage is an orthogonal issue from issue format. With a standardized issue format, it could be stored in a database or git, and as long as the service had an open export function, it would require no lock-in. Also, as some have pointed out here, storing highly relational data like issues and connected profiles, etc, could be an exercise in frustration if you tried to store all that in git. At the very least, it would be limiting.

numbsafari 8y ago
Agreed. This reminds me of people in the healthcare space who advocate for blockchain as some magical way of resolving integration issues. The absence of a robust, well adopted and supported format, is the greater reason for integration issues. Changing the storage and distribution format might bring certain benefits, but it doesn’t solve the core problem.

sytse 8y ago

Storing things like issues in git is possible. But it makes it harder to make functionality on top like upvotes and issue boards. Not impossible for sure but it slows down development. And it would only help with portably if rate limits are the problem. So far GitHub rate limits for logged in users are decent, we migrated 200k projects in 48 hours. Even when you store issues in repos the format would likely differ between different tools. If the format differs it is just as easy to write an importer that uses the API.

sametmax 8y ago

Even if I ended up migrating from github, I would still look for a centralized instance. Why ? The price for one migration in a few years is not a big deal compare to self hosting, which is a human resource hog for small entities. I have more important things to do than to deal with deploy, configure, maintain, document, secure, and test my own instance. I really don't want to admin one more server just for that. I don't want to play cat and mouse with spiders, brute forcers or DDOS events. And I do want a huge visibility and community around the tool I use. And my users may not want to create yet another account to open a bug ticket.

Walkman 8y ago
I feel like everybody is overestimating the cost of self hosting. I run my own instance of GitLab, but the "costly" part was setting it up and making backups. Since then I just "apt-get upgrade" and there is a new version and that's it. Since I set it up, I haven't touched any of the configuration files. The availability guarantees are much easier to keep for a small team than for thousands, so you don't really have to worry about that either.
- themacguffinman 8y ago
  You're ignoring the cost for community projects where the community now needs to invest in learning and using your own self-hosted repo, which may or may not have a good UX. This is a barrier to entry.
  - Walkman 8y ago
    I agree with this, but the cost is centralization and single point of failure.
    - sametmax 8y ago
      Sure. No free lunch. It's just important to understand the nature and size of the costs, so that you can make the trade off adapted to your context.

komali2 8y ago

This site on mobile lol, how did this even happen: https://i.imgur.com/4AbIEuz.png https://i.imgur.com/4AbIEuz.png

jkaplowitz 8y ago
Looks fine on my Google Pixel (Chrome, Android 8.1). But yeah the site's rendering on your phone seems broken indeed.
fredsted 8y ago
For some reason there's a height property on the nav bar, which prevents it from expanding when the browser is wrapping. When removed it looks fine.

dschep 8y ago

There exist multiple solutions that store issues in git: * https://github.com/duplys/git-issues https://github.com/duplys/git-issues * https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue

chatmasta 8y ago

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.

neilk 8y ago

When you couple services together, you decrease the potential user base. For example, Github issues are underpowered for many people. But at least you can ignore them and use your own service. Many source control systems tried to offer all-in-one platforms but it’s never worked so far. In fact, we don’t even do PRs the way the authors of git intended. For integrations, it might be better to settle on a configuration file format and maybe some conventions. Maybe that could be checked into your repo. But then you need fine-grained control over who can modify that, and encryption to keep passwords secret, and those aren’t standard features of source control either. Maybe we could come up with conventions that were great for hobbyists and the enterprise. But open source communities and standards committees are really bad at that, compared to just leaving it the marketplace.

twblalock 8y ago
Plus, even if Git did have all of the features people want today, people will continue to think of new features that are not supported by Git and need to be implemented outside of it.

vsviridov 8y ago

https://sit.fyi/ https://sit.fyi/ allows you to keep your issues in the github repo itself. It's written by https://news.ycombinator.com/user?id=yrashk https://news.ycombinator.com/user?id=yrashk

Rjevski 8y ago

If anyone has a good idea for a format/protocol to store issues & pull requests in Git itself, I'm all ears. There is a reason why every single product uses a separate database for those.

yrashk 8y ago
I've worked on this in SIT project (https://sit.fyi https://sit.fyi). While the core is generalized, the very first module available for it is issue tracking and I've been using it for a few months now. It enabled some scenarios previously difficult/impossible to achieve -- for example, merge requests can contain updates to issues as well, allowing one to make non-trivial updates to issues once their patch is merged in (for example, open a dozen of new issues [todo list for improving the new feature], leave comments, etc.)
jwilk 8y ago
Separate (orphan) branch, which contains one markdown file for each issue/PR. If you figure out how to encode comment metadata and other pesky stuff like PR reviews, this should be both human and machine-readable.

BillinghamJ 8y ago

This isn't entirely true. GitHub's wikis and the gist system are both backed by git - because it makes sense for those. It wouldn't make so much sense for issues, pull requests, etc. If they were backed that way, they'd very likely be rather slow to query (as GitHub doesn't keep the latest data in a "checked out" state). Not to mention the fact that you can just ask them for a data export and they'll provide it all to you happily in JSON format. This post doesn't really have much reality backing its criticisms.

jelder 8y ago
Came here to say this. That wikis and gist are backed by git is very useful. Trying to wedge issues etc into a git model would be an engineering disaster; these are clearly problems best solved with a database. There may be valid criticisms about MS GitHub, but this isn't one of them.

Boulth 8y ago

Git appraise stores PR data in git repository: https://github.com/google/git-appraise https://github.com/google/git-appraise

danmg 8y ago

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 just a side benefit and not altruism. What they were after was Electron, since that's a very popular way of writing desktop applications currently.

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

trexen 8y ago

"out of the trap we now find ourselves in." The anti Microsoft panic about GitHub feels childish and pedantic. Perhaps if there was some evidence post acquisition of Microsoft trying to do unpalatable things then there might be room to complain. But just to knee jerk advocate leaving GitHub because you are a Microsoft hater lacks credibility and comes across as whining and silly.

PretzelFisch 8y ago
I don't know how these groups have the time to worry about what-ifs. It's better to just play wait and see. Does MS make GitHub worse, does Google buy a git provider to compete. To many questions to take action right now.

MrBurrito 8y ago

If you are in the EU, you have the right to take the data with you. Thanks, GDPR. https://ec.europa.eu/info/law/law-topic/data-protection/reform/rights-citizens/my-rights/what-are-my-rights_en https://ec.europa.eu/info/law/law-topic/data-protection/refo...

smg 8y ago

Yet another way to store issues in the git repo https://gitlab.com/monnier/bugit/ https://gitlab.com/monnier/bugit/ This one is by Stefan Monnier (former emacs lead developer)

mikece 8y ago

The idea of including wiki and issue tracking as part of the repo is a great idea to include in my OpenVersionControl spec idea -- https://news.ycombinator.com/item?id=17242015 https://news.ycombinator.com/item?id=17242015 Of course Fossil has exactly what you're suggesting.

EGreg 8y ago

What happened to this: https://keybase.io/blog/keybase-chat https://keybase.io/blog/keybase-chat Encrypted github support!

KaiserPro 8y ago

The massive rush to migrate from github is childish at best. To put that in context, I lived through MS's various attempts to kill off competitors (Yes, I paid for netscape.) I've worked with LDAP/kerberos and cursed the weird schema changes that are AD. But that was > 15 years ago. I'd gladly pay for AD, even more if its a linux based infra. (Hmmmmm kerberos) Github was loosing cash, had a toxic culture (Abuse of power, side effects of sexism, and then hiring people for being agitators instead of coders.) Microsoft has the money, time and power to improve the product, fire the arseholes and make sure that github is in some sort of shape in the long run. Just look at the alternatives: atlassian, or worse still oracle/IBM. So sure, migrate to gitlab, Its a good product, when its working. Github has many faults, but reliability isn't one of them.

deleted 8y ago

[deleted]

parvenu74 8y ago

So is the main complaint that GitHub is a closed-source, proprietary product? Or is it that they don't provide you with an "export all of my code, issues, wiki, conversations, social graph, etc to GitLab" button?

servilio 8y ago
The criteria he proposes is about your second point: an easy way to ensure you are able to export all the data that you can later import somewhere else. The second part of this is as important as the former, a pretty "Export" button is useless if the data can't be used later to replicate your project somewhere else. The opening paragraph is also very on point about the negative effects of Github on the Git ecosystem.

marcinkuzminski 8y ago

I don't agree with the author here. Over the years i read about using VCS to store underlying data, so it's all shared, and you keep the data. Reality is that building a complex source code management platform is not easy. Storing things inside GIT repo and not database would be a huge performance issue when we're talking about scaling such system. If you have 1 repo yeah, it's doable and easy, but if you're talking 100 000 projects that's another story. This problem keeps returning onto HN again, and again. I think this simply wouldn't work for mentioned reason, and few others that come to my mind. And i know a bit about building a source code management platform because I built RhodeCode.