Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The single most important criteria when replacing GitHub

joeyh.name

Post reply on HN
Print view View original

21–30 of 135 posts

Re: The single most important criteria when replacing GitHub

#21

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

Re: The single most important criteria when replacing GitHub

#22

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

Re: The single most important criteria when replacing GitHub

#23

Post by Walkman »

sametmax wrote: post #13

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 d…

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.

Re: The single most important criteria when replacing GitHub

#24

Post by mkirklions »

RyanCavanaugh wrote: post #8

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.

I didnt understand why this mattered either.

One is storage of data that can be downloaded whenever, the other is basically a comment field.

Re: The single most important criteria when replacing GitHub

#27

Post by amelius »

chatmasta wrote: post #21

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

> I’m highly skeptical of coupling the issue tracker and other non-VCS features with git.

But isn't it nice that you can say "issue X has been solved in commit Y"?

Re: The single most important criteria when replacing GitHub

#28

Post by crossman »

RyanCavanaugh wrote: post #8

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.

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

Re: The single most important criteria when replacing GitHub

#29

Post by RussianCow »

amelius wrote: post #27
chatmasta wrote: post #21

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

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

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.

Re: The single most important criteria when replacing GitHub

#30

Post by [deleted] »

chatmasta wrote: post #21

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

[deleted]
Post reply on HN