Thank you for your feedback and addressing your concerns. It's through conversations like these that we can continue to refine our platform.
> 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.
I completely agree that an overly complex system could negatively impact end users. However, our goal with the use of blockchain is to introduce new features and possibilities while striving to maintain the interface and workflow as familiar as possible for developers. That being said, we are continuously working to minimize potential drawbacks such as performance issues or slow updates.
> 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.
Just to clarify, we are not embedding the entire git repository on the blockchain, that will be an overkill. We only store the refs[0], access rights on the chain, which is the most critical information about the repo state. So, the chain's here is not to serve the repository but to keep a tamperproof record of the repository state (refs), who all have access to modify it and anyone can verify the history of these updates on the chain along with the collaboration history.
> 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.
Clarifying again here that we are not embedding the entire git repository on the blockchain, that will be an overkill. We only store the refs, access rights on the chain, which is the most critical information about the repo state.
And since git already has data integrity checks for the objects, we can just serve the repository objects/packfiles from a separate data store.
We did explore git-bug and git-issue for issue tracking, but decided to implement the issue tracking on the chain itself for supporting additional features (bounties, for example) and better user experience.
> 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.
Your final point on full decentralization versus a new plutocracy is well taken. The token-based governance isn't designed to create a plutocracy but rather to encourage involvement from the community. The ideal is that each stakeholder would be more motivated to contribute and partake in decision making. We can't deny the fact that GitHub has been one major factor in bring the open source development to the mainstream. And we strongly believe the importance of a common place for open-source code collaboration. Projects using their own self hosted git server and their custom tooling will miss out on new contributors and visibility, unless they are well established like Linux, bitcoin, etc.
That said, we're aware this model isn't perfect. We're open to suggestions and continuous iteration is part of our process.
[0] https://bigdipper.live/gitopia/transactions/B4CEB69B08DE82D9...