Decentralize Git Hosting, We Must

When I was thinking of a name for a place where makers from all over the world could congregate, share and collaborate freely, I could only think of one word — Ellcrys. A term I learned from watching the movie series Shannara Chronicles. Ellcrys was a mystical tree that kept out demons that used to disturb and dominate the elven population. The tree became their (the elves) their source of strength and protection. I thought that open source collaborators and end-users of their products could use an Ellcrys against the big corporations competing to control our data, right to have a choice and a voice within their platform. I mean, why not?

• We (Users) create so much data that has applications across many other applications and use-cases but we are not afforded the right to export or connect with other services for their own competitive reasons. I may be interested in a newly launched service that may benefit from my social graph, spending or location history but I may not be allowed to conveniently export my data to the new service. Even when users are able to connect via APIs, they usually don’t get all available data and access can be severed at any time.
• We have no say over how they use our data. In some jurisdictions, there exist laws like the GDPR that attempt to regulate how users’ data is used but these laws either create poor user experience or are not respected or strongly enforced.
• Big corporations do not really care what users think or want. They listen but will only do the things that benefit shareholders — It’s understandably their duty. However, it kind of sucks when users are heavily invested in a product they care about and it changes in ways they never saw coming. I love playing Apex Legends, a battle royale game that has seen many in the community asking the developers to remove skill-based matchmaking but they continue to ignore. This scenario occurs in other more critical platforms.
• Everyone talks about how the internet has made it possible for people to launch almost any kind of business and build their dreams. But we forget that these dreams are built on the back of (almost) monopolies like Google, Amazon, Facebook and GitHub who are ready to de-platform you for ever-changing reasons. You could have a YouTube channel with millions of followers today, then tomorrow you are destroyed because of a rule or algorithm change. Google Search is famous for changing the search ranking algorithm in ways that produce a really wicked outcome for small businesses.

Do you see it? We really need protection and consideration. Unfortunately, we will never be able to get shareholder-centric organizations to truly take us, our opinions and desires seriously.

We need to re-invent the organization structure that is responsible for managing the products and services that we rely on. We need user-centric organizations that not only respect users because we make them money, but we also need to be valued because we are people with needs, dreams, voices, individual aspirations and families. They need to put us first.

A root problem — Shareholders

Forget it, these huge platforms will not become user-first any time soon. It is not because the founders do not want to or are bad people. It is due to the practices that have been built over generations that only serve to benefit the people who finance the product in its infancy — The shareholders. These founders are legally required to do one thing only; They must increase the value of the company at almost any cost and as long as they abide with the laws in jurisdictions they operate in. In cases where they overstep, only the government is able to call them to order, it is usually never the users.

User-first Ideals

We believed that the best place to start change was to bring transparency into how software is developed. We figured that we can create a user-first product and experience if we:

• Let users into the discussions and processes that lead to the adoption of an idea over another. They will have a deep understanding of the product and love it more.
• Let users help to build part of the product so they can have a sense of ownership and strive to support it on a daily basis.
• Open the codebase so users can see for themselves how the product works. They will be able to see what will be changed in the next release. There will be less contention if users understand the features of a new release because they had the chance to discuss and contribute to it.
• Put in place a process that allows users to participate in critical decision making such that their voices count. A product can remain owned by founders and shareholders but still give users a chance to contribute to governance. While they (founders + shareholders) may keep revenue, they cannot hurt users through bad product changes.
• Allow users to retain ownership of their data by deliberately building for the application to use the users’ data as opposed to the application owning the data in silos that require permissions to access.
• Build products/features that embrace open standards that allow users’ data to be conveniently exported, important and parsed without issues. Just this feature will create more jobs and foster an ecosystem of connected applications.
• Application builds, deployment and execution are transparent. Let users be able to tell what version of a product has been deployed. A user-centric application may also grant users the power to decide what should be deployed or executed.

You might wonder how all these can be put in place by one company; These are fundamental issues that will require an entire industry to change. But we don’t need the entire tech community to start adopting the highlighted ways towards user-centricity, we just need the free and open-source software community.

FOSS Community = 😍

The open-source software community is responsible for most of the software products and services we use freely today. The products built and maintained for free by open-source contributors powers many of the applications we use and love today. The community continues to give even to big corporations who rarely, selectively or don’t even give back to the community. Only a community with an altruistic nature and a love for experimentation will be able to spearhead the ideas that would lead to a more open and fair application ecosystem for users.

An Obstacle we Love

Today, it seems like we have all the things we need to start to build user-first products and services. We have:

• A community of open source developers eager and willing to build important things.
• An already thriving and growing ecosystem of people committed to building, supporting and financing public goods (ex. Bitcoin, Ethereum, Crypto VCs and many more).
• Big corporation consistently misbehaving and making users increasingly aware of the need for a change.
• Financially incentivized speculators whose activities help to incentivize the work done by thousands of developers building legitimate, open and publicly accessible services.

This is great right? Yes. But we have a problem and it is centralized code collaboration platforms like GitHub. In this future where open source collaborators build user-first applications, the repository and its community will form an organization. This organization needs self-sustenance. It needs self-sovereignty. It needs to make its own rules. We will need a platform that gives powers to a source code repository on which we will build this brave new world that is an embodiment of ideas we discussed earlier. Unfortunately, this will not happen any time soon. For instances, these services cannot or will not:

• Allow a product’s repository to be co-owned by more than one account. Collaborators cannot truly co-own a codebase, end-product, and development data because it is not possible to share them on centralized infrastructure. GitHub cannot provide an answer to the question: How can thousands of developers co-own a repository and its community. The very nature of the technology it's built on does not support such an ownership structure. It is possible to build server-side feature to add multiple accounts as owners but such ownership is not real as someone must still take responsibility and pay usage bills. If the ownership of a codebase cannot be truly shared, it will not be possible to share the end-product.
• Guarantee a censorship-free platform. Centralized code collaboration platforms have shown in many cases that they are willing to censor developer communities at any time and at the request of third-party. The controversy around GitHub’s takedown and reinstatement of youtube-dl is a testament of the threat open source communities face, even on platforms that have been historically good for OSS. In truth, GitHub has no choice in the matter most times, it just needs to follow the law of the land. It is worrying to think that we as citizens of nations not under the authority governing GitHub will still be subject to their rules.
• Self-governance and non-interference. If repositories become the new organizations, they will definitely need to be able to create rich governance structure. The question now is: Who will enforce these governance structures unbiasedly, at all times? We cannot count on GitHub to be fair in executing governance instructions and remain neutral for obvious reasons (ex. stakeholder interest, third-party and government coercion).

Though we love GitHub and its equivalents, we need something else to host these organizations built on git repositories. A tool that not only enforces user-first ideals but also embraces it at its core.

The Ellcrys Rises, then Catches Fire

Photo by Henrique Malaguti on Unsplash

So in 2017, I and Odion created a company named Ellcrys with a goal to create a decentralized version of GitHub but with all the qualities required to bring about the vision of a user-first software ecosystem. At the time, the project was the first of its kind. But it was also a very troubled company as we struggled for a long time to sustain and grow the team because we were inadequately funded. Eventually, we let the team go while Odion and I decided to try again with what we now call MakeOS (Make Open Source). We spent the last 16 months refining and coding to get to a point where we can begin to showcase what a decentralized code sharing and hosting system will look like.

MakeOS — A protocol for code hosting & sharing

Armed with lessons we learned from the previous attempt, in September 2019, we started a new reference implementation for a code collaboration protocol that is built on top of git and leverages the qualities of distributed ledger technology. MakeOS is a product of the following technologies:

• Git: The most popular distributed version control system that millions of developers rely on to effectively share and organize a codebase. Developed by Linus Torvalds in 2005 for the development of the Linux kernel. It has since been integrated into many tools and workflows developers depend on today. Like GitHub, MakeOS provides a place where open source developers can store their repositories; Share their codes, accept and review code contributions, manage access and more.
• Distributed Hash Table (DHT): A DHT allows us to share the data that we need to store across many connected computers across the world. The data we store in this storage system is the git objects of repositories. Unlike GitHub, MakeOS’s distributes repositories across many computers on its network ensuring that repositories cannot be easily removed, censored or tampered with easily. This property is important as organizations existing wholly as repositories need to be protected from often contentious takedowns. It would be super difficult for an adversary to effect a removal; they must find and instruct everyone on the network to comply.
• Blockchain: Like the DHT, a blockchain is a distributed storage system that replicates an authenticated database across many computers in a network. Its different from the DHT in that data is collected into a chain of blocks where each block references the authenticated ID of the one before it. This structure protects the integrity of data across the network, ensuring that no change can be made to historical data and without the networks agreeing. We use this technology to create identities for developers; They can use their blockchain identities to interact with others. We also use it to set and enforce ownership, access and governance instructions for repositories. MakeOS is built on the brilliant Tendermint Core framework which allows us to process transactions quickly.

MakeOS Participants

As a network protocol, MakeOS needs the help of people who will contribute compute resources to enable the network to perform its functions. Currently, there are 4 kinds of participants that are instrumental in keeping the network healthy and useful. They are:

• Validators: These are people who manage the MakeOS blockchain system. They are responsible for ordering transactions into blocks. They collect transactions, validate and process them using a globally shared set of rules. Validators process transaction like fund transfer, push request, governance alterations and more. As proof of stake system, anyone can become a validator if they have a minimum stake in the system. The stake is there to protect the network against Sybil attack. The protocol pays validators using a native digital currency.
• Hosts: These are the participants that provide permanent storage infrastructure for the network. They run computers that operate on the DHT network providing git data to users and replicating existing and new ones. Anyone can participate as a Host and provide service for one or more repositories they care about. However, the network pays a limited number of hosts to consistently provide services for all repositories.
• Remote: A remote is a computer on the network that serves user-facing git service. It provides the functions that are normally available on platforms like GitHub. The beauty of MakeOS remote services is that they are just interfaces over a protocol that democratizes code hosting and sharing. Anyone can run a personal or public remote service. Also, users can jump from one remote to another without losing their data (repositories, issues, merge request, discussions, assets, identity etc). Although anyone can operate a remote service, the protocol will pay a limited number of remote operators to act as designated remote services providing zero-cost access to code hosting and collaboration services.
• Miners: A Miner uses their computer to perform hard mathematical puzzles to produce an output that allows it to create something called Dilithium. This process of creating Dilithium is known as Proof-of-Work. Dilithium is the ingredient that is required to create Latinum, the main currency of the MakeOS network. 🖖

Development Status

MakeOS is actively being developed. As of today, we have a beta client version and a testnet that anyone can try. If you want to try it, check out our documentation and website to get started.

Initial Dilithium Mining

Due to the nature of Proof of Stake, we will need to bootstrap the network with over 50% of the initial supply of the native coin (named Latinum). These coins must be created and locked as a security bond. Since Dilithium is required to create Latinum on MakeOS, we need to start the process of mining Dilithium before the launch of the network on Q4 2021. We are inviting anyone who wants to participate and support the project to join our mining program. We have created a cloud mining platform that allows the participant to rent compute capacity to mining Dilithium. Currently, we are offering a free shared miner for 30 days. The longer you wait to join, the harder it gets as the proof of work difficulty continues to rise. You can rent more compute power to improve your mining capacity and to support the project. Head over to our miner page to learn more.

Happy new year!