First off, I think decentralizing off of GitHub is a worthy endeavor, so kudos for working on it! That said, I do have some questions:

First, why blockchain? I know it's a bit of a meme around here to be instantly critical of any blockchain project, but I genuinely am not sure what a blockchain provides here over git itself, which is already a distributed version control system.

Second, why a new token? Transaction fees and maintainer donations can easily be handled with existing payment providers and (if desired) ETH/BTC. What is a new token contributing towards the goal of a decentralized GitHub?

> First, why blockchain? I know it's a bit of a meme around here to be instantly critical of any blockchain project, but I genuinely am not sure what a blockchain provides here over git itself, which is already a distributed version control system.

git is distributed, we use git as well and it is irreplaceable. The hosting platform till now has been centralized and prone to censorships due to the jurisdiction it was based in for eg US sanctions. A decentralized platform that uses a blockchain provides censorship resistance out of the box.

> Second, why a new token? Transaction fees and maintainer donations can easily be handled with existing payment providers and (if desired) ETH/BTC. What is a new token contributing towards the goal of a decentralized GitHub?

The payment providers need KYC or valid jurisdictions to operate under. ETH/BTC could work here(can also work on gitopia in the future). But building just on top of another network restricts us to their limitations. On the other hand having your own network enables us to change along with the requirements of the platform. The new token contributes to the security of the platform as it is used by validators to secure the network via PoS consensus. The token also acts as a governance mechanism in voting for governance proposals that shape the future of the platform. This won't be possible by relying on existing tokens.

> git is distributed, we use git as well and it is irreplaceable. The hosting platform till now has been centralized and prone to censorships due to the jurisdiction it was based in for eg US sanctions. A decentralized platform that uses a blockchain provides censorship resistance out of the box.

This is an argument in favor of decentralizing, and I'm 100% in agreement. However, you haven't really explained what the blockchain layer is providing here that couldn't be accomplished with git's native ability to be a distributed VCS. There's a lot of overhead introduced by adding a blockchain—extra development time, extra code to maintain, extra CPU work (even with PoS). In order to persuade a technical audience to use your tool, you have to explain what value all that complexity is bringing!

Put another way: I can have a distributed, censorship-resistant VCS by self-hosting Forgejo and mirroring repos that I like and want to help keep online. If a tool like Foregjo could encode the issue tracker and other meta information inside the .git folder, it could even make those aspects distributed, without all the complexity inherent in a blockchain. Given that, what does blockchain bring to the table?

> There's a lot of overhead introduced by adding a blockchain—extra development time, extra code to maintain, extra CPU work (even with PoS). In order to persuade a technical audience to use your tool, you have to explain what value all that complexity is bringing!

Agreed that there is a lot of overhead introduced, but that is for the development of the platform and network of Gitopia. For the end user the workflows remain almost the same for collaboration.

> Put another way: I can have a distributed, censorship-resistant VCS by self-hosting Forgejo and mirroring repos that I like and want to help keep online. If a tool like Foregjo could encode the issue tracker and other meta information inside the .git folder, it could even make those aspects distributed, without all the complexity inherent in a blockchain. Given that, what does blockchain bring to the table?

I understand that this would work for technically inclined users but not for everyone who want to contribute to open source. Along with this the blockchain layer layer offers immutable, transparent and tamper proof versioning of code along with the collaboration meta and augments the current collaboration flow. Along with this it enables us to provide a novel means to incentivize open-source contributions along with fostering a more decentralized approach for governance (even for projects), every token holder could have a say in the decision making, reducing the risk of undue influence by a single party, hence eliminating centralized control.

I will also add that we have tried to keep the flow of collaboration on Gitopia as intuitive as possible for the developer hence adding no additional complexity for the end user if they don't want it. But for some projects this might be useful or necessary to use the web3 workflows along with the collaboration features on Gitopia.

> but that is for the development of the platform and network of Gitopia. For the end user the workflows remain almost the same for collaboration.

I have to disagree here. Accidental complexity in a system can have severe downstream impacts on end users, whether that be in the form of poor performance, unreliability, or just slow update cycles. It's not something you can paper over and completely hide from the user.

> Along with this the blockchain layer layer offers immutable, transparent and tamper proof versioning of code

Tamper-proof can be accomplished natively by signing [0]. receive.denyNonFastForwards and receive.denyDeletes[1] can be used to make a git repository immutable. Git commits are also already content-addressable. And transparency is achieved by just having the repo available for people to clone.

> along with the collaboration meta and augments the current collaboration flow

Could this augmentation not be accomplished by storing the collaboration information in the repo under a set of special-purpose branches? Like git-bug[2] or git-issue[3]? Coupled with GPG signatures and you've got your immutability and tamper-protection, too!

And to be clear, I'm not suggesting we should just tell people to use these tools instead of giving them a good UI for it, I'm suggesting we should use these tools as the underlying mechanism for a decentralized GitHub. Build a great UX on top of git instead of embedding git in a blockchain.

> Along with this it enables us to provide a novel means to incentivize open-source contributions along with fostering a more decentralized approach for governance (even for projects), every token holder could have a say in the decision making, reducing the risk of undue influence by a single party, hence eliminating centralized control.

This one I'll grant you, but it's by far the least compelling aspect of the project to me. I don't think we're going to solve the centralization of GitHub by centralizing on a new plutocracy, I'd much rather see efforts towards full decentralization. There's nothing inherent to Git that requires that we all use the same set of servers.

[0] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

[1] https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura...

[2] https://github.com/MichaelMure/git-bug

[3] https://github.com/dspinellis/git-issue