Open Source Contributors’ New Home — The HDE
Looking at trends and creating win-win scenarios for open-source developers and open-source software projects alike.
Software is eating the world — and at an increasing speed. Not everybody needs to become a developer but there are certainly more arguments for than against being able to navigate the digital realm with confidence.
The world not only needs developers but also people feeling confident about how software works, how it is built and what challenges are associated with building it. A great way of getting to know what software development means, is getting involved in the world of open-source software (OSS) development. This world is hidden in plain sight — on GitHub, where few non-technical people ever go…
While many have never visited this place, more people than ever before are collaborating on OSS projects. And there are good reasons for it.
If you are just getting started with software development it is a great way to learn and to find likeminded people. You have a place to ask questions and you will quickly understand that people expect you to be proactive, but are very helpful and supportive if they see that you are willing to learn.
“Those who know, do. Those that understand, teach.” ― Aristotle
If you are an experienced developer, OSS projects can be just as valuable to you. It is a way for you to build a “portfolio” of contributions that can help you find a new job. You can also improve upon your mentoring skills, and help less experienced developers. This might not sound very appealing at first, but helping others can be a very rewarding pastime. (Some of) my teachers used to tell me that teaching is one of the most satisfying things to do. After working for my local university for almost six years now, I can only voice my wholehearted agreement.
Creating a Win-Win Scenario
Horizen is an open-source blockchain platform. Our code lives on GitHub. You are free to go explore it and get involved in its development. There is a problem with getting started on OSS development today, though: it can be intimidating to navigate GitHub at fist, even for someone who knows his code. Although there are many great guides, tutorials, and help pages it does take some time to get a grasp of the structure, the workflow, the conventions and communication styles there. Repositories, issues, branching, forking, and merging — commits and pull requests — it takes some getting used to.
There will always remain a level of complexity to working on OSS, but we believe that we can abstract some of it away in order to make it easy for developers to get started. Once you have a starting point, you will easily learn the rest just by sticking around.
Hello HDE
The Horizen Developer Environment — HDE — sets out to make it easy for developers to get started on their first open-source project and get to experience the benefits of becoming involved in a community of like-minded people.
At the same time, this will help the Horizen platform grow. A recurring theme in the blockchain world applies — vires in numeris.
Vires in numeris — or “strength in numbers” — applies to OSS projects as well as to most other endeavors. The more you are, the more you can achieve — given a key condition is satisfied: a certain level of structure is provided!
The High-Level Structure
In the case of the HDE, this structure is manyfold. The Horizen Developer Environment Platform will focus on enabling collaboration, making contributing to our project fun and adding incentives for quality contributions.
It will be founded on two pillars: The GitHub process will add more structure to the collaboration on GitHub and Zen Improvement Proposals (ZenIPs) are a decision making process and governance mechanism that will be applied to new feature requests and proposed protocol changes. It is an established process in many of the larger blockchain projects.
The GitHub Process
A first step will be refining our GitHub Process (GHP). The GHP will apply to all the work that is done within our GitHub repositories. This starts with some general guidelines for how we expect contributors to collaborate and discuss. Each project on GitHub has a readme file that outlines what the project is about and that provides the minimum information for an experienced OSS contributor to get started.
Next, you will usually find a contributing file. It contains some guidelines for how people should contribute to the project and what the general scope is. It serves both the contributors and the maintainers. While contributors have a way to verify that they are submitting appropriate pull requests and are opening useful issues the maintainers have a document to refer to when declining a pull request or issue. Instead of having lengthy discussions about why a contribution is inappropriate, one uses this document as a reference.
There will be a few more things defined in our GitHub Process, such as how to write proper commit messages and what constitutes good documentation.
Another crucial step will be adding capacities to the Zen Blockchain Foundation. We want to be able to provide guidance for new as well as experienced developers working on our codebase. Not only will we try to help out when people are stuck, but we also want to support skilled contributors growing into leading roles themselves. Repository maintenance and community management will be critical for the GHP.
Zen Improvement Proposals — ZenIPs
Protocol Improvement Proposals are an established mechanism to decide upon new features and core protocol changes in many blockchain projects such as Bitcoin (BIPs), Ethereum (EIPs) or Zcash (ZIPs). We believe that it is not necessary to reinvent the wheel so we will adopt our own version of an improvement proposal system — the ZenIPs — as a governance mechanism. You can think of a better name? Please comment ;)
A ZenIP in and of itself is a document that describes a new feature. It explains the rationale behind the proposed feature and elaborates on why certain design decisions were made.
The ZenIP Process starts with an owner or author proposing a new feature in the form of a ZenIP. The community now discusses the proposal and can make suggestions on how to improve upon it.
Once the drafting phase is completed and the ZenIP is accepted it will be added to a designated repository for all ZenIPs that are to be implemented.
The implementation of an accepted ZenIP will be subject to the previously described GitHub process. An issue or project will be created in the appropriate repository and finalized there. If the ZenIP makes changes to the core protocol the specification of the protocol needs to be changed accordingly before the code can be merged and go live.
So far nothing spectacular, but briefly describing the governance mechanism as well as the execution process sets the scene for the HDE Platform.
The HDE Platform
The Horizen Developer Environment Platform will be the focal point for the development of the Horizen ecosystem.
First, we want to make it as easy as possible for people willing to contribute to finding tasks that will move the project forward. I myself was in that position just about one and a half years ago: I reached out to the back-than ZenCash team to figure out what I as a non-developer could do to help — now I’m part of the Zen Blockchain Foundation myself. We know first-hand that many people are willing to help out, but we just haven’t done a good enough job so far at making it easy to get started.
The HDE platform will help all community members that are motivated to contribute with finding a task appropriate for them. GitHub is a great platform for developers, but not so much for less technical people. Some non-code related things community members can do is to plan events, provide designs, provide translations and write articles or tutorials. We believe that just by highlighting the many ways people can get involved, we will see an influx of helping hands.
Developers can also benefit from a more structured approach to discovering issues appropriate for them. This relates to a clearly defined label policy which is part of the GitHub Process but can be extended beyond it.
Open source development is naturally based on collaboration and we think we can improve the collaborative experience for our community with features such as team requests.
If you find an issue that you would like to tackle, but you don’t feel confident doing it by yourself, you could add a team flag to it, so other contributors in the same situation can reach out to start working on it together with you. There are many ideas floating around as of now, and we are just getting started on this huge endeavor but we are excited to share our vision with you at this point.
Summary
The HDE comprises three main workstreams: defining the GitHub Process, establishing the Zen Improvement Proposal decision making process and building a platform for efficient collaboration and incentivization of contributors. Holistically, this feels like a monumental task to tackle. But I will do my very best to make this vision become a reality sooner than later.
I see this project not just as an important step towards improving Horizen, but also a chance to set a precedent for the open-source software community as a whole on how community engagement can be increased and developers as well as the projects themselves can benefit.
Not every step towards the HDE will be accompanied by a Medium Post (although I’ll try to do a few of them), so you might want to follow Horizen on Twitter if you wish to stay in the loop. I also appreciate a follow on twitter, so feel free;)
