
The single most important criteria when replacing GitHub - edward
http://joeyh.name/blog/entry/the_single_most_important_criteria_when_replacing_Github/
======
chatmasta
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.

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

~~~
simplyinfinity
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 projects, but it's paid for teams and
enterprises. it's a win-win situation where they do social good and get paid
for private service.

Alternatives & competition is good, but too much competition is not that great
either in this case.

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

~~~
simplyinfinity
Correct, capitalism isn't inherently evil, competitions is healthy. That's why
we have github, bitbucket, sourceforge,gitlab,gitea,phabricator, and probably
few more projects like this. however imagine if we had thousands and the open
source community was give or take evenly distributed between them. that would
simply be nightmare. discoverability will be pretty low, contributions will be
even lower and the community wouldn't be thriving as it is now. path of least
resistance and all that..

~~~
mmt
> imagine if we had thousands

First you spoke of 50, then 500 (web sites), now thousands (yet you only
managed to name 6).. this is starting to resemble _reductio ad absurdum_.

You haven't really made a convincing argument for why we might have excessive
variety, such as an unusually low barrier to entry compared with other open
source tools.

Moreover, I'm pretty sure your arguments could also be used in favor of
federation, rather than centralization.

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

~~~
MBCook
How often do you test your backups? How many places (physical) do they exist?
How often are they taken?

What’s your server’s uptime? Is it highly available? How often do you patch?
Do you test them first? How do you keep up with security updates from other
software on the machine(s).

How is your security team in general? Do they monitor for stolen credentials?
Do pen-tests? Watch for network scans and attacks? Look for weird traffic
patterns?

Do you have redundant network links? Backup generators? Do you test them? Sure
your datacenter SAYS they have them, but remember when Intuit went down for 2
days a few years ago? I bet they had told their bosses they had generator
backups.

Is someone always on call? What are they experts in? How do you get support?

GitHub provides a TON of stuff above a cheap VPS or EC2 instance. And that’s
not including the network effects of having so many projects in the same site.

~~~
Walkman
> What’s your server’s uptime? Is it highly available?

Who cares about uptime, when you use a server alone or with a small team? It
can be down for 10 hours and you would not even notice.

You don't understand what you need.

> How often do you patch?

I patch the machine multiple times a week with some "apt update && apt
upgrade" which takes literally less then a couple of minutes a week.

> Do you test them first?

I don't need to because I'm using ZFS and make a snapshot before upgrades, so
in case of a disaster (which already happened multiple times) I can roll back
within minutes, which happened multiple times, once when the machine didn't
even booted.

> How is your security team in general? Do they monitor for stolen
> credentials? Do pen-tests? Watch for network scans and attacks? Look for
> weird traffic patterns?

You don't need any of that. If you think you do, you think you are far more
important than you really are. Maybe framework authors or super-popular
library writers would need to worry about that, but self-hosting makes you an
order of magnitude lower chance of being a target.

> Is someone always on call? What are they experts in? How do you get support?

We might not talk about the same thing...

> And that’s not including the network effects of having so many projects in
> the same site.

This is the only valid point you came up with.

~~~
mmt
I'm not sure what to call this counterpoint to the more general mantra of
"cloud is cheaper and easier than rolling your own!" (with an implied "always"
in the middle).

Maybe the ineconomy of scale? Except it's not really about scale but about
customization, so maybe the "economy of customization".

> You don't understand what you need.

Unfortunately, I think this statement is more often true than not, and it's
much easier to go with what's popular right now than to form that
understanding.

Of course, there's some merit to that strategy if one is new, but I can't
believe that many people are that new.

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

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

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

------
nwah1
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\))

~~~
gowld
[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
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.

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

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

------
nartz
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
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
that says > NOSQL database

which is an important limitation.

~~~
icebraining
Why is it an important limitation in this case?

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

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

~~~
amelius
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
> 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
Still doesn't explain why projects should be all in one place, as opposed to
spread over the internet.

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

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

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

------
vsviridov
[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)

------
tschellenbach
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
Nobody cares that they make money. They care about it not being open source or
having easy-to-migrate data (lock-in).

~~~
throwaway28921
Strange that people are only caring that it's closed source and locked in
after MS bought them.

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

------
Senderman
Criterion.

~~~
bahjoite
"And this kind of pedantry feels like a tactic."

Astonishing that this was the response to a comment which offered-up le mot
juste.

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

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

------
smg
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)

------
MrBurrito
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/refo...](https://ec.europa.eu/info/law/law-topic/data-
protection/reform/rights-citizens/my-rights/what-are-my-rights_en)

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

------
dschep
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)

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

------
Boulth
Git appraise stores PR data in git repository: [https://github.com/google/git-
appraise](https://github.com/google/git-appraise)

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

------
EGreg
What happened to this:

[https://keybase.io/blog/keybase-chat](https://keybase.io/blog/keybase-chat)

Encrypted github support!

------
komali2
This site on mobile lol, how did this even happen:
[https://i.imgur.com/4AbIEuz.png](https://i.imgur.com/4AbIEuz.png)

~~~
jkaplowitz
Looks fine on my Google Pixel (Chrome, Android 8.1). But yeah the site's
rendering on your phone seems broken indeed.

