SIA coin is a similar concept. They even have video hosting/streaming on their development roadmap.
Decentralized storage, filesystem and social media seem to be the most valuable use–case for blockchains aside from the inherent value of cryptocurrency.
It's funny that there's already a Gitcoin project, however they do NOT have a token:
https://gitcoin.co/
The goal of the project is to incentivize FOSS development, similar to Bountysource, except without requiring participants to trust a central party. It's pretty cool!
The issue is that the features we use along with git, many of which github provides, are not decentralized. The true but tired argument that git will continue to work when github goes down totally ignores this issue.
Yes, git still works. But we don't just rely on the features git provides.
So this isn't really anything to do with Git then is it? So why joke we centralised Git when really we centralised a bunch of other things that are not really anything to do with Git?
You can still work with your colleagues by pushing and pulling your own repos without involving GitHub.
I think centralised CI is the real problem. I don't have the compute power in my home to run our full test suite, so I can't push with confidence without my CI cluster.
Issues and other GH infrastructure is arguably a bigger problem. That metadata is locked within the Github silo with no easy way to export it elsewhere.
GitLab CI is really sweet, because you deploy your own runners (workers) whereever you want. Downside is, the control is not a standalone CI app but a part of GitLab (or I'm unaware about something).
Drone is very promising but last time I've checked the documentation had some holes in it. The website is "coming soon" and IIRC it's like this for quite a long while.
I'm unaware about any CIs that are usable with local repos. Would be neat to just run a local command and it would spawn a worker somewhere (local or through a remote coordinator) and run the tests on whatever I have in the working tree, just like it happens with centralized repo+CI combos.
It's too frequent I find myself doing `git commit -m 'Fix that stupid typo in previous commit'`.
We centralized a decentralized communication system too. (eMail)
Decentralization just doesn't work too well in practice for whatever reason. Everyone is behind a NAT/firewall, everyone has low computing power, its hard to regulate, etc. This all leads to a centralized solution being easier.
I think the current best thing we have is centralized but open source and encrypted, which gets an "okay"/10 from me.
> Decentralization just doesn't work too well in practice for whatever reason.
Because it's inconvenient. Centralisation is convenient, it gives a single discovery and synchronisation point. Decentralisation makes discovery much more difficult, and requires adding separate synchronisation mechanisms. It generates friction and cognitive overhead.
Even more so for "side-services". Sure your VCS is nominally decentralised[0], but what about bug reports? Contributions? Notes & docs? There were distributed bug trackers efforts back in the early 10s but… they didn't really work IME, they were not convenient or practical.
[0] though even without a single giant point of failure, most project would still have a single canonical master copy, a really mesh/distributed contribution system is very rare (Linux's tree of integrators/forks is probably the closest?) and none of the current VCS makes mesh/point-to-point collaborations really convenient
That's kind of missing the point, everyone's git local clones are still there, I can still work on the code. Git's decentralisation is meant to make sure work doesn't stop altogether when the remote is down.
The major feature of git is that it's distributed, not that it's decentralized.
Git's got two big features over SVN:
1. Automatic, private, per-user branching. Git's even nice enough to keep the private branches out of the main repository, and lets you pretend to be the authoritative repository without creating a branch if you really want to. This is what clone/push/pull actually does, and it's what a distributed VCS really brings to the table. It lets every dev pretend to be the project manager when they're writing their own code.
2. A much improved merging model. The graph model of git is just much better than the linear model of SVN.
The second one is what people thought they wanted when they started using git. The first one is what they didn't know they wanted before they started using git.
Git gets around the problem of "Well, if we do #1, how do we know which repository is authoritative then?" by saying, "We're not solving that problem. This is an exercise for the users that's easily solved by file permissions." So by refusing to solve that (rather hard) problem, the VCS becomes internally decentralized. That doesn't mean you can't or shouldn't centrally manage your repositories or have an authoritative repository. It's just that git itself doesn't care about knowing which repository is authoritative.
The VCS is still decentralized (you can share code with your neighbour or across the world), it's the administration (tickets, PRs, etc) that aren't.
I think it'd be fairly straightforward for github or a competitor to store those things in git as plain markdown files, either alongside the main source code, or (as it does with GH Pages) in a separate branch (that has nothing in common with the master branch but it's still in the same repo).
No way to build my npm dependencies.
So the day github would really crash/lost some files, the package decency system thing is dead.
That is a very exciting scenario... as exiting as if google would forget to renew google.com and would have no legal right to get it back.
shawabawa3|8 years ago
coding123|8 years ago
jradd|8 years ago
Decentralized storage, filesystem and social media seem to be the most valuable use–case for blockchains aside from the inherent value of cryptocurrency.
https://sia.tech/whitepaper.pdf
thinkmassive|8 years ago
The goal of the project is to incentivize FOSS development, similar to Bountysource, except without requiring participants to trust a central party. It's pretty cool!
mhluongo|8 years ago
vuldin|8 years ago
Yes, git still works. But we don't just rely on the features git provides.
chrisseaton|8 years ago
chrisseaton|8 years ago
I think centralised CI is the real problem. I don't have the compute power in my home to run our full test suite, so I can't push with confidence without my CI cluster.
TAForObvReasons|8 years ago
drdaeman|8 years ago
Drone is very promising but last time I've checked the documentation had some holes in it. The website is "coming soon" and IIRC it's like this for quite a long while.
I'm unaware about any CIs that are usable with local repos. Would be neat to just run a local command and it would spawn a worker somewhere (local or through a remote coordinator) and run the tests on whatever I have in the working tree, just like it happens with centralized repo+CI combos. It's too frequent I find myself doing `git commit -m 'Fix that stupid typo in previous commit'`.
ReverseCold|8 years ago
Decentralization just doesn't work too well in practice for whatever reason. Everyone is behind a NAT/firewall, everyone has low computing power, its hard to regulate, etc. This all leads to a centralized solution being easier.
I think the current best thing we have is centralized but open source and encrypted, which gets an "okay"/10 from me.
masklinn|8 years ago
Because it's inconvenient. Centralisation is convenient, it gives a single discovery and synchronisation point. Decentralisation makes discovery much more difficult, and requires adding separate synchronisation mechanisms. It generates friction and cognitive overhead.
Even more so for "side-services". Sure your VCS is nominally decentralised[0], but what about bug reports? Contributions? Notes & docs? There were distributed bug trackers efforts back in the early 10s but… they didn't really work IME, they were not convenient or practical.
[0] though even without a single giant point of failure, most project would still have a single canonical master copy, a really mesh/distributed contribution system is very rare (Linux's tree of integrators/forks is probably the closest?) and none of the current VCS makes mesh/point-to-point collaborations really convenient
naiveai|8 years ago
da_chicken|8 years ago
Git's got two big features over SVN:
1. Automatic, private, per-user branching. Git's even nice enough to keep the private branches out of the main repository, and lets you pretend to be the authoritative repository without creating a branch if you really want to. This is what clone/push/pull actually does, and it's what a distributed VCS really brings to the table. It lets every dev pretend to be the project manager when they're writing their own code.
2. A much improved merging model. The graph model of git is just much better than the linear model of SVN.
The second one is what people thought they wanted when they started using git. The first one is what they didn't know they wanted before they started using git.
Git gets around the problem of "Well, if we do #1, how do we know which repository is authoritative then?" by saying, "We're not solving that problem. This is an exercise for the users that's easily solved by file permissions." So by refusing to solve that (rather hard) problem, the VCS becomes internally decentralized. That doesn't mean you can't or shouldn't centrally manage your repositories or have an authoritative repository. It's just that git itself doesn't care about knowing which repository is authoritative.
nickysielicki|8 years ago
The point of git is that everyone can keep working right now and can push later without things getting very messy.
peterwwillis|8 years ago
edit: Oh jesus christ, there's a fucking tech company called Square Wheel. Kill me now.
neosavvy|8 years ago
runeks|8 years ago
I can’t push changes to the decentralized Git protocol, only to a (centralized) server instance.
hashkb|8 years ago
dorfsmay|8 years ago
If you want issues, CI etc... Then you need a local version of github which you will pay for.
Cthulhu_|8 years ago
I think it'd be fairly straightforward for github or a competitor to store those things in git as plain markdown files, either alongside the main source code, or (as it does with GH Pages) in a separate branch (that has nothing in common with the master branch but it's still in the same repo).
Similar (maybe) is ADR (http://thinkrelevance.com/blog/2011/11/15/documenting-archit...), storing architectural decisions into numbered files in git. See also: https://github.com/npryce/adr-tools
Conan_Kudo|8 years ago
[1]: https://pagure.io/pagure
dehef|8 years ago
golergka|8 years ago
kuon|8 years ago
mmahmad|8 years ago
Edit: Nvm, found out Gitlab has the mirroring feature (https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...). Pretty cool!