GitHub recognizes that it has a role in the development of open source code. For starters, and as a platform, GitHub obviously hosts a great deal of it. As a product, GitHub's primary and presumed workflow is like that of an open source project, with loose or disaggregated networks of project maintainers, contributors, and users. And even as a corporation, GitHub has at times attempted to organize itself according to open source models, experimenting with non-coercive, collaborative, and geographically disparate structures of corporate organization.

GitHub's internal legal counsel wishes to discuss what GitHub can do to help existing open source projects thrive, to support new projects and new contributors, and to promote the development of the open source community. More specifically, and given GitHub's unique vantage point, GitHub Legal is working on projects utilizing tools of governance and process to contribute to open source in new ways. We wish to present the details of an "Open Source by Design" project in four parts.

The first part relates to altering the default understanding as to what it means for a project to be hosted without an explicit license on GitHub. We show why we need to tread with care when we alter this default, which data we are collecting that is intended to help us choose the new default wisely, and where that data seems to lead.

Our second part aims to help introduce governance infrastructure to open source projects in order to solve problems that such projects may some day face. We place particular focus on problems that, in GitHub's experience, often hamper open source projects as they transition along some relevant axis, be it user makeup, maintainer makeup, rate of adoption, commercial developments, design disputes, ownership disputes or the like. We believe that by developing and offering some measure of template governance structures, much confusion and many challenges that bedevil open source projects may be avoided.

We are sensitive to the potential side-effects of such a project, such as the stifling of alternate project organization and governance models. Another interesting aspect of study would be to what extent, if any, such bottom-up models of project self-governance would influence, supplement, or even act take on the role of law as they themselves became subject to things like increased adoption and standardization. This question seems particularly relevant in areas where formal legislative intervention is light.

The third part of an "Open Source by Design" project would be a new compliance service that aims to help projects comply with license requirements of third party code that they use, to avoid license inconsistencies where they actually occur and flags preventing the neglect of licensing.

Finally, we've given much thought to the metrics by which we would gauge the success of the different steps of this project once implemented and that could help us plan the second stage of the project.