Proposition for running SDG market as a git extension using Python

Introduction

What is your open source project worth? The SDG market seeks to answer this question through a distributed initiative to give a monetary or token value directly to contributions. As of writing, the SDG market exists as a web application where people can track the market value of projects open on Github. For those unfamiliar, it is essentially a website where such open projects can be published. Currently, the value is calculated as a function of the change contributed by each contribution called commits in git jargon. The proposition is to unlock the mechanisms proposed by the SDG market and use them in a decentralized manner independent from Github. The idea is to make the market easily extensible, distributed, compatible with existing workflows and to do all that in respect of the existing open source community at large. The question remains: how?

Extensible

In order to make the project more extensible, we thought to make it a lightweight command line tool would be best. That is why we are presently working on git-market a command line tool based solely on git and gitPython as the interface enabling us to retrieve and analyze commits. The motivation is to bring the whole project together frontend and API under one single language. Thus making extensibility much easier also by the fact that python is an easy language to pick up. The case of smart contracts gives us a good example of how this might work. Presently the project uses a Levenshtein function on the difference between a new commit and the pre-existing text or code in order to give a value to the contribution. This could be viewed as a very basic smart contract that pays a developer in function of how much he contributes. This is a relatively good idea and would work pretty well for documentation or applications that aren’t code libraries or APIs themselves. However, it might arise that a user realizes that they actually want to base the attribution of tokens based on the usage of a functionality. With the proposed approach, the user can write such a function in Python or retrieve the information from an online interface and send this information to our token generation method. For example, one could simply view the number of downloads or other simple metrics from a repository and use this to compute a value relative to the contribution. The strongest incentive for developing smart contracts in such a manner is that they are easy to write and can be just as easily understood since python has mature tools for literate programming. We would only need to define a framework for writing these contracts in such a way that they are humanly and legally understandable just like they would be machine understandable.

Distributed

Since GIT is already a decentralized version control system and we essentially make sure that the value can be kept or computed on the fly in a similar decentralized manner, the mechanism is by default distributed if we don’t rely on the API of a centralized site such as Github for example. Of course, talking about smart contracts and decentralization comparisons to cryptocurrencies are bound to arise. We should be wary of throwing around such buzzwords since they have a certain connotation despite the potential benefits of such technologies. Instead, I want to suggest we focus on what makes such technologies solid and what can be learned from them. If we look at git it is pretty close to a distributed ledger already in the sense that it is completely decentralized and every user can have a local copy of the ledger making tampering difficult. The challenge for us if we want to take advantage of what makes these ledgers so solid will be making ours tamper proof with some kind of signature-based commit system or at least signatures for every time value is transferred. This is doable through GPG signatures, which are a form of numeric signature, where we would require at each value computation that the value is registered as a signed commit that can’t simply be rolled back. A second challenge will also be having a strong consensus mechanism since presently git is rather individualized which is fine for code but not acceptable for a store of value. This is still a challenge that will require reflection during implementation before money ever comes into question.

Workflow compatible

Our aim is to have a tool which anyone could run using a simple command or an interface. The git market command would make it possible to instantly evaluate the worth of a repository or branch locally. One of its greatest strengths is that it would use the exact syntax that so many developers are already familiar with namely git push, git pull or git commit. Thus making it trivial to integrate into one’s existing Workflow just adding one stop to check how much one’s work might currently be worth. This would even make it possible for a developer to know the value of his work before even pushing to a server based centralized repository like the current SDG market. This localizes the process leaving for greater privacy too. And for the less technically inclined it would also be trivial to integrate the process in existing graphical version control tools that already rely heavily on GIT.

Respectful of the community

Another important point if we want to work in synergy with the open source community is to respect the existing institutions and standards. It is important that we understand how important the community is to us. Our project is a code project first and foremost we are going to need a strong community if we want to move forward efficiently. One important tenant of open source is licensing. As can be evidenced by the Redis and *MongoDB cases two extremely promising open source projects turned businesses that tried twisting their licenses to secure a profit. Resulting in their projects being defined as closed source, forked and the community potentially turning away from the original projects. The verdict is not yet said on these projects but more and more they are getting attacked by the tenants of the larger open source community. That is why I think extensive reflection on licensing is going to be necessary. On the one hand, a strong copyleft license like the GPL seems fitting to a project where the whole goal is to enable people to control their revenue. On the other hand, if we actually want people to be able to use the project it would be more interesting to use a freer license like an MIT or a BSD license. In any case for revenue generation, it is going to be necessary to reflect on either dual licensing or building additional services such as data aggregation or selling funds on top of the open source project. Dual licensing and data aggregation would pose a problem in the sense that we could end up having a conflict of interest between developing the open source project and selling our licenses or services. That is why selling a perpendicular service like the third option suggests seems ideal in terms of business model and respecting our community more on that in a future post.

Conclusion

The two main goals of SDG market as an institution will be on the one hand open source sustainability and on the other democratizing open source development. It is pretty clear that git-market is more geared towards the first goal but if we are able to solve the first it gives us a solid foundation to attack the second.

*[14.03.19] UPDATE:

Regarding the existing sustainable projects such as MongoDB as of today. Amazon has built what they call open distros as in open distributions of MongoDB and elastic search to compete with the existing hybrid projects.