Proposal Details
Proposal #310
Proposal title
Revise Open Source Funding Policy
Submit time
Deposit end time
Voting start time
Voting end time
Tally result
Proposal #310 description
This proposal is intended to supersede Prop #59 and Prop #64 should it pass.
Summary
Juno Network embraces a culture of open-source development given that it allows builders to continually innovate on existing products and provides developers an opportunity to verify source code for user safety. Additionally, we want to create an environment where builders feel they can retain ownership of front end code that provides them with a competitive edge in the marketplace. Achieving a balance between open-source and closed-source will be important to attract, retain and encourage builders to make Juno their home.
Background
In the past, projects have received large sums of funding from Juno Network and were not required to open source their smart contracts. This meant that other teams on Juno were unable to innovate on these foundational products. This also presented a safety risk given that users and developers could not verify the codebase of smart contracts responsible for handling large amounts of user funds.
Prop 59 was the first proposal to require that Juno only fund open source projects, and while well intentioned, it was broad and non-specific. Prop 64 was drafted in an effort to bring more clarity to the exact funding bodies and funding terms (ie, past projects grandfathered in and open source requirement applied to mainnet smart contracts). However, Prop 64 has conflicting language which should be amended to ensure sensical compliance and user safety.
It is clear that smart contracts deployed on mainnet should be open source in order to promote transparency and allow for further innovation on the products funded by and deployed on Juno. This is in alignment with Juno’s ethos as a builder and community centric chain. However, it is not clear that there is any benefit to open sourcing front end code, as in many cases, the user experience provides projects with an edge over their competition. Forking front end code may give an unfair advantage to projects who have a war chest of funds to deploy, especially given that many of Juno’s developers are grassroots teams.
Motivation
While well intentioned, the current wording of Prop 64 warrants that all components of projects funded by Juno’s CP or subDAOs be fully open source. We are now in direct conflict with this as DAO DAO has closed their front end source code. Also other teams, like WYND, might have different workflows where they release sourcecode only when ready for mainnet deployment, developing privately during the initial stage of new features. The spirit of the open source proposal was to safeguard users of the network using dApps, however its current wording is not acceptable, and must be amended to ensure sensical compliance and continued user safety.
New policy
Moving forward, we propose the following rules for all projects receiving funding on Juno Network; whether it be from Juno's SubDAOs or Community Pool.
- Smart Contract code must be open source prior to mainnet deployment, so that anyone can review it or use it as inspiration for building new products.
- Teams may choose to work on Smart Contract code privately during pre-deployment phases of development. This allows teams to innovate and test new features before any user funds are at risk.
- Teams receiving funding will be required to provide the entity providing funding with regular reports of development progress, and these reports will be subject to non-disclosure terms.
- Teams are free to keep their frontend / client / APIs & Indexers code closed source indefinitely to retain competitive advantage. We highly encourage teams to open source their code with a restrictive or business license, but recognize that not all teams have the funding to legally enforce these licenses.
These rules apply specifically to projects being funded by Juno's SubDAOs and Community Pool. Beneficiaries or developers receiving funding from Juno are not required to open-source work that is unrelated to their specific funding deliverables, such as individual side projects.