Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC 1789 — Stable Funding for Open Source Maintainers #1789

Closed
owocki opened this issue Feb 28, 2019 · 22 comments

Comments

Projects
None yet
8 participants
@owocki
Copy link

commented Feb 28, 2019

(Join the Inflation Funding Working Group)

ERC 1789 — Stable Funding for Open Source Maintainers

A Proposal for Inflation Funding for Protocol Maintenance

Table of Contents

Intro

Hi there.

My name is Kevin Owocki and I am a co-founder of Gitcoin. I am co-authoring this proposal to sustainability fund Ethereum Development with other members of the Ethereum community; In particular, @ameensol has been a very valuable co-author.

This ERC is a proposal to fund ongoing ecosystem stewardship with inflation funding. As a starting point, we propose that 20% of the issuance rewards (both transaction fees + block rewards) are allocated for ecosystem stewardship.

In this ERC, I will break down my argument into four basic sections:

  1. Why ecosystem stewardship is important
  2. Why ecosystem stewardship inflation funding is the right approach
  3. Administration of funds
  4. Tuning of parameters

My goal for this ERC is to establish a strong argument for (1). Stewardship is the most important driver of long-term value creation in the Ethereum space, and open source communities more broadly. Rewarding maintainers of Ethereum is critical. I am willing to die on this hill.

Sections (2) (3) (4) are arguments that are more loosely held, and serve to start the conversation. My goal for the ERC is to facilitate discussion on each of these topics.

Without further adieu,

1. Why ecosystem stewardship is important

I define ecosystem stewardship as:

  • Protocol maintenance
  • Protocol design and development
  • Support for education, evangelism, acceleration of and about the Ethereum ecosystem

Despite the tremendously large use of Open Source Software by companies around the world, Open Source Software has historically had a problem sustaining itself. Even though Open Source Software creates $400 billion in economic value yearly, there has not been a rational economic reason to work on open source software. There is more upside available in the private sector, working for high growth startups.

Because of the above reasons, 65% of Open Source Projects have only one or two maintainers. The foundation of our public digital infrastructure is being supported by benevolent billionaires at best, and in spare hours on nights and weekends at worst.

This is clearly not sustainable. In recent years, we have seen the symptoms of this problem,

  1. Developers who are running major projects are quitting.
  2. The Heartbleed Bug, a serious vulnerability in OpenSSL, created security holes at every major internet company.
  3. A hacker infecting a popular Node.JS repository

Each of these symptoms are merely examples of the core problem of there not being enough funding and support for Open Source Software. The world gets open source software for free, and they take for granted that developers will keep it maintained.

If one projects these trends into the future, it is not easy to imagine a critical bug created in an important project. Will we wake up tomorrow and discover that a security hole destroyed billions of dollars in value? Will our most important repo's continue to have few developers who suffer from lack of funding?

Recent hope from the blockchain ecosystem

Recent innovation within blockchain protocols has provided a glimmer of hope for OSS maintainers and those interested in it's further development. Because open blockchain protocols commonly have native tokens (some worth billions of dollars), there is now more funding available for open source projects to build than ever before. This coincides with a tangible financial incentive to pay maintainers - if a maintainer builds valuable software, the value of the token they work on rises.

Specifically in Ethereum, there is millions of dollars of funding available from the ECF, the EF, and Consensys Grants. (Disclosure: I am an advisor to Consensys Grants). There are also prominent ICOs that have launched OSS Grant funds (Status Incubate, Aragon Nest). These organizations have a rational economic incentive to support Open Source:

  1. They want to widen the lead of Ethereum over other smart contract platforms.
  2. They want to bring more developers into the ecosystem.
  3. They want to make sure that developers who are working on important projects (like ETH 2.0) can focus on their work.

2. Why ecosystem stewardship cannot be properly funded without inflation

Funding for core Ethereum infrastructure today should be:

  • sustainable
  • predictable
  • consensus driven
  • transparent
  • impactful

While these ecosystem funds are great, the ECF, the EF, and Consensys Grants will not be around forever. While the financial holdings of each of these grant programs are not publicly available, it is clear they do not have infinite runway. It is surmised in the Ethereum community that while the Ethereum blockchain will be around for a very long time, the Ethereum Foundation does not plan to be around (at least in it's current iteration) 10+ years into the future.

More Details From The Community

It is worth noting that a few prominent members of the community have laid out their vision for how long, and within what scope, innovation should happen in Ethereum.

From Lane Rettig:

My vision is of an Ethereum that continues to innovate until we’ve achieved maturity along four dimensions, at which point the base layer should become stable, and innovation should occur at layer two and above, with two exceptions: fixing bugs/critical issues and public good issues which must be tackled at layer one. Those four dimensions are 1. scalability, 2. usability, 3. governance, and 4. adoption.

Per Vitalik Buterin:

At this point in time, and in the medium term going forward, it seems clear that decentralized application platforms, cryptocurrency payments, identity systems, reputation systems, decentralized exchange mechanisms, auctions, privacy solutions, programming languages that support privacy solutions, and most other interesting things that can be done on blockchains are spheres where there will continue to be significant and ongoing innovation.

I believe that the upcoming innovation in the Ethereum ecosystem will be measured in decades, not months or years. This timeline is significantly longer than the runway that the funding from the aforementioned Grants programs provides.

Exhausting other options beyond inflation-funding

For these reasons, it is incumbent upon us as a community to find new and sustainable ways to fund Open Source Software.

I have a unique purview on this problem, having spent the better part of the last two years focusing on Gitcoin’s Mission, to Grow & Sustain Open Source.

Did you know that there is a movement happening in the broader Open Source ecosystem, called SustainOSS? There is a broad collection of Open Source sustainability mechanisms that the SustainOSS community has put together. From Nadia Eghbal’s Lemonade Stand, they are:

1.	Donation button
2.	Bounties
3.	Crowdfunding (one-time)
4.	Crowdfunding (recurring)
5.	Books and merchandise
6.	Advertising and sponsorships
7.	Get hired by a company to work on project
8.	Start a project while currently employed
9.	Grants
10.	Consulting
11.	Paid support
12.	SaaS
13.	Copyleft + paid license
14.	Open core
15.	Foundations and consortiums
16.	Venture capital
17.	Restricted license

I have discussed these mechanisms in large part on this post. TLDR: How do we solve the burnout loop for software developers in OSS? We we think sustainability options which meet the following criteria are the only options:

.	High funding potential
.	High time coding
.	Alignment with values

Unfortunately, many of the tried and true funding mechanisms won’t work at ETH-Scale.

  1. Donation Buttons and crowdfunding do not have high funding potential.
  2. Consulting, paid support, books / merch take away from time coding.
  3. Getting hired, whether full time or paid, Venture Capital, does not always align with our values. There is often roadmap-capture by the funders of OSS.
  4. A SAAS model, restricted license, open core, or paid license are not options for the Ethereum infrastructure given its open source, permissionless innovation.
  5. Advertising and sponsorships take time away from coding, and often do not have high funding potential.

We at Gitcoin have spent the last two years traversing the cartography of funding options for Open Source Software, and we keep on coming back to one place.

The one and only place to achieve sustainable funding that has the following characteristics is inflation funding.

  • High funding potential
  • High time coding
  • Alignment with values

These three characteristics represent a necessity in meeting the motivational needs of developers. It fundamentally recognizes the reality that people will not dedicate nights and weekends to Ethereum forever, and we want to bring full time developers into the space on an ongoing basis.

While the mechanics of inflation funding are up for conversation as this ERC unfolds, we feel strongly it is the right mechanism to ensure alignment of incentives for maintainers of Ethereum infrastructure. It simultaneously serves as an example to other open source platforms on the value of the mechanism.

3. Administration of funds

There are many avenues on administration of funds received through inflation funding. We will add some of these for discussion, to add color to ways the 20% block reward can be appropriately allocated.

We think it makes sense to consider the following two paths as we explore this problem:
A. What is the optimal long-term solution?
B. What is the first thing we can put to the test?

We suspect that while there will be some overlap between the two groups, they will require very different methodologies. The first is more theoretical while the second is more experimental. A fine place to start, in our view, would be adding support for collecting block rewards to each client, with a parameter that could be set, controlling the portion of the reward to be captured (and the beneficiary). This mechanism would be initially set to 0%, and could be edited via some on-chain mechanism or via a hard fork. The hard fork option is safer and probably less controversial since the on-chain option raises tons of questions around keys and governance.

It's worth mentioning why this isn't being proposed for something like Bitcoin. Bitcoin is intended to stay the same, while Ethereum is intended to evolve. Part of the reason this ERC makes more sense now than it did last year is because Ethereum's evolution is accelerating in the presence of other smart contract platforms. I suspect it will take 1-2 years at least to ramp up to 20% inflation rewards to stewardship, but as the EF fades and the ecosystem grows more competitive the community will increasingly see the logic of this action. I just hope it isn't too late by that point, which I why I think it's great timing that you're starting this discussion now.

This being said, administration of funds should be considered a ongoing topic of discussion, outside of the main topic of the ERC - securing 20% of block rewards for maintainers of Ethereum.

In practice, we recommend adding support for collecting block rewards to each client, with a parameter that could be set, possibly via some on-chain mechanism, controlling the portion of the reward to be captured (and the beneficiary). Initially the parameter would be set to zero, but adopting the ERC and implementing the code is making a credible commitment to the community that if another solution isn't found, and a reasonable amount of funds collected by some point in time, then we will "turn on the faucet" and begin collecting block rewards.

Criteria for Administration of Funds

We propose these criteria when evaluating

  • Decentralization of decision making authority across a representative sample of community members.
  • Fund administrators should be accountable for their decisions.
  • Instutional capture of fund dispursement should be avoided.

Existing models

Consensys Grants, the ECF, and the EF have been deploying capital to help accelerate the space, and we should take best practices and learnings from those teams, and apply them in whichever model we choose. In the short to medium term, we imagine these programs would receive a yearly budget via block rewards, upon which there would be transparent reporting around which projects those funds support and the reasoning.

DAO-based models

In the spirit of decentralization, I believe that administration of funds from inflation funding should be administered via DAOs that are accountable to the community, and to their participants.

In making this proposal, I would like to first acknowledge the long road we’ve got ahead of us when it comes to DAO research and development, especially with respect to this use case. In the spirit of decentralization and trustless technology, we are not used to giving a lot of discretion to actors to administer funds and deploy capital. Many of the protocol maintenance, development, and design tasks that need to be done require abstract thinking, vision, and strong execution. Thereby, it will be important to design a DAO which both simultaneously holds itself accountable, but also has the capacity for abstract, thoughtful consideration of funding proposals.

One promising advancement for DAOs in this space is the recent mainnet launch of MolochDAO. Moloch operates through the submission, voting on, and processing of a series of membership proposals. I am looking forward to the results form the first MolochDAO experiments, and I am cautiously optimistic that Moloch could be forked and adjusted for the purposes of this ERC.

Another promising project that is administering funds to support Open Source Software Development is Gitcoin Grants. (Full Disclosure: I am a founder of Gitcoin). We recently ran an experiment in CLR Funding for Open Source Software and raised $50k for ETH 2.0 projects in the first round. Details here.

We should also note that Open Collective has pioneered, in many ways, what an organization that is transparent by design, would look like.

I am looking for collaborators who are knowledgeable about DAOs. Please see the “Get Involved” section below.

4. Other ideas and tuning of parameters

This proposal is based in part upon the funding model for the ZCash Foundation, in which “80% of the newly created ZEC will go to the miners, and 20% ZEC to the founders.” As we design a system for the Ethereum community to consider, I believe there is much to be learned from the ZCash model.

As mentioned in the introduction, my goal for this ERC is to establish a strong argument for (1). OSS Stewardship is the most important driver of long term driver of value creation in the space. I am willing to die on this hill.

Sections (2) (3) (4) are arguments that are more loosely held. My goal for the ERC is to facilitate discussion on each of these topics. In particular, I’m interested in hearing the community debate various mechanisms for supporting OSS in the Ethereum space.

Off the top of my head, here are some variables we can tune: (this list is not exhaustive)

  • percentage of inflation funds distributed to DAOs
  • number of DAO participants
  • governance / accountability model of DAOs
  • how long DAO members can sit in the DAOs
  • where funds are deployed once they are on the DAOs

What inflation funding rate is correct?

Team Gitcoin has started to model what we think the correct amount of inflation funding is. Here is a snapshot:

As you can see, if this ERC is successful and 20% of the block rewards go to developers, then $98mm / year will be distributed to developers. According to our models, this is $43k per dApp, $196 per developer in the space.

We look forward to revising this model with the help of the Ethereum community.

One consideration that we advise the community to take into account is, that because Ethereum is so vast, it's going to take a long time to get widespread buy-in for inflation funding stewardship at all so it might as well be large enough that it's worth the coordination cost to even talk about. Miners are getting ~$500M/y at these prices so even 1% is $5M over the course of a year. Starting with 0.1% ($500K) seems like a waste of time, maybe 1% is the minimum. You could pay ~33 devs $150k/y with that.

Storage rent

It is possible that we could fund parts of the ETH community OSS dev via inflation, as discussed on EthMagicians.

Dynamic provisioning of fees

One interesting idea that was shared with me last night by a prominent member of the space is that, when the community releases a new fork (Byzantium to Constantinople for example), they could scope the next fork, and dynamically allocate a different percentage fee based upon the scope of the next fork and the consensus for said fork.

Counter-arguments

In forming this proposal, I did my best to anticipate possible counter-arguments. Here is the output from that process.

This proposal reduces miner incentive to secure the chain

I anticipate this proposal will generate a fair amount of pushback from miners, and possibly stakers. A miner has a rational economic incentive to argue that, without 100% of the issuance rewards, they are not properly incentivized to secure the blockchain.

Before addressing this argument, I would like to acknowledge that I have worn both hats in my career. I have been both a miner and a developer over the last several years. I have deep empathy for both parties, and believe that there is a rational economic that increases the size of the pie for both parties.

My counter-argument to this point is that this proposal will increase the size of the value of the Ethereum ecosystem sufficiently that miners will actually make more profit in the long-term by securing a better, more sustainable ecosystem. By ensuring that the best and the brightest in the ecosystem can work in the Ethereum ecosystem on important maintenance and protocol tasks, we will

  1. avoid critical security issues whose fallout could destroy billions of $$$ in market cap overnight.
  2. increase the likelihood of the next “unicorn” being created on the Ethereum stack, thus increasing the value of the entire Ethereum ecosystem.

One interesting thing to note when it comes to miners paying software developers, there is a precedent: proprietary miners (like Claymore) that give 1-3% of the mining rewards to the developers of the mining software.

HODLers

There is a counter-argument that developers who HODL ETH have enough of an incentive to maintain the protocol. I believe that this argument is naive, for the following reasons:

  1. Not all devs have large ETH HODLings.
  2. We need to bring more talent into the space.
  3. For the talent that we do bring into the space, there needs to be a rational economic incentive to work in the commons.

In Conclusion

This ERC is a proposal to create sustainable funding for projects in the Ethereum commons.

This proposal funds ongoing ecosystem stewardship with inflation funding. As a starting point, I propose that 20% of the issuance rewards (both tx fees + block rewards) are distributed to the stewards of the Ethereum ecosystem.

In this ERC, I broke down my argument into four basic sections.

  1. Why ecosystem stewardship is important
  2. Why ecosystem stewardship cannot be properly funded without inflation
  3. Administration of funds
  4. Tuning of parameters

My goal for this ERC is to establish a strong argument for (1). Stewardship is the most important driver of long-term driver of value creation in the space. I am willing to die on this hill.

Sections (2) (3) (4) are arguments that are more loosely held. My goal for the ERC is to facilitate discussion on each of these topics.

Get Involved

To get involved in the working group for this ERC, please comment on this thread or engage with the project board here.

There is also a telegram group for the inflation funding working group.

I am particularly looking for collaborators who:

  • are willing to put in sweat equity
  • can think and respectfully debate from first principles
  • are passionate about the mission of Growing & Sustaining Open Source
  • have knowledge of how to design / deploy a DAO
  • have a demonstrated track record in either the OSS or Ethereum communities
  • have knowledge of the ZCash model

Special Thanks to Nick Miller, Jeff Scott Word, Ameen Soleimani, Dan Lipert, Scott Moore, Vivek Singh, and XYZ who reviewed this ERC before it was submitted

We are standing on the shoulders of Giants. In particular, this ERC was inspired by thoughts from Fred Ehrsam, Luke Duncan, Spencer Noon, Vivek Singh, Jorge Izquierdo and others

Further Reading

We recommend the following writing for further exploration of this topic:

  • Funding the public good - this is still a work in progress and needs to be updated to reflect the current state of Moloch, ECF, and some other stuff
  • Token curated bounties - an idea I was working on last year, you can ignore the second half as this idea is half-baked, but the first half lays out the same problem.
@GregTheGreek

This comment has been minimized.

Copy link

commented Mar 2, 2019

NOTE: I'm going AFK and will add to this further tomorrow.

I'm elaborating on a twitter thread as I think it adds useful context to this:

Basically, there exists a networking issue that needs to be solved.

Issue:
How do we broadcast and validate that the actual values (above) are correct, while allowing for the values to be dynamic?

A few conditions:

  • We assume that you can dynamically change the address that the funds want to be sent to.
  • We assume you can dynamically change the % that you want to send

A barebones example:

In ETH1.x we could have the miner could sign a message (with their private key) stating the address to send to and the allocation amount. This could be stored in the extra_data field, and we could reserve a key for it, perhaps something like:

redirect: { 
  to: ....,
  alloc: ....
}

Where to is a valid eth address and alloc is a percentage of the block reward. The computation
could occur during the rewards portion in the clients. For example, in Geth I would assume we would do the calculations in the accumulateRewards() found in consensus/ethash/consensus.go. Reading out the extra_data field, validating the signature and then allocating rewards accordingly.

In Eth2.x we could follow a similar pattern although we need to further spec out how our messaging will look. I believe the recent Wire protocol should help with that.

Edit 1 - formatting.
Edit 2 - Note at the top

@zhous

This comment has been minimized.

Copy link

commented Mar 4, 2019

A huge and exiting project! Good luck!

@owocki

This comment has been minimized.

Copy link
Author

commented Mar 5, 2019

As a next step, I would like to find a technical partner who could help me implement a reference client that supports this ERC. If anyone knows someone who is interested in doing so, pls let me know.

@GregTheGreek

This comment has been minimized.

Copy link

commented Mar 5, 2019

@owocki
This would be a fun challenge due to some of the complexities...
I can implement it into Geth.

@bmann

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

@owocki this doesn’t really follow an EIP process. I think it would be more helpful as a blog post that points to a (future) actual EIP.

Specifically I’d like to engage with the content but I don’t want to mess up the EIP registry with something that is a long form discussion.

Does that make sense?

I’m happy to help format this as an EIP that can be submitted as a PR and merged as a draft. I’ve gone ahead and setup a repo, put this content as the README, and added the EIP template. https://github.com/spadebuilders/eip1789

Note: I couldn’t copy the Markdown source from your issue so the README will need to be updated.

@owocki

This comment has been minimized.

Copy link
Author

commented Mar 5, 2019

@bmann thanks for the feedback. feedback is a gift!

i was treating this issue as a ERC (which i understand stands for Ethereum Request for Comment), not an actual EIP (Improvement Proposal). The actual EIP will come later, after we've built economic models, designed a DAO, built a technical reference implementation ,etc.

I'm tracking tasks for this at https://github.com/gitcoinco/ERC-1789/projects/1

For the long form discussion, I'm happy to use the above repo, the repo you set up, ETHMagicians Forum, Google Groups, or something else. Let me know what you prefer... We are debating where the working group for this initiative should live within team Gitcoin this week!

@owocki

This comment has been minimized.

Copy link
Author

commented Mar 5, 2019

@bmann derp. i just s/EIP/ERC/g in the post to make it consistent with our comment above. thx!

@corollari

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

I hope I don't come across as really nitpicky but ERCs are actually proposals for "application-level standards and conventions" , and therefore should be used to propose standards on the application level. Your proposal doesn't fit into that category.

This comment may seem aggresive, I've been trying to rephrase it for about 30 mins and I don't know how to do it so I'll just state it explicitly: please don't take it as aggresive, I'm just trying to provide information.

@expede

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

@owocki

First off, let me say thank you for getting the ball rolling here. Proposing a block-reward share for core infrastructure has been on my todo list for several months now (just so busy with multiple other EIPs 😅). Core infrastructure is underfunded and what funding there is often directed at cool new shiny projects. We need some kind of sustainable model if we want things to move forward for years to come. Taking a kind of block reward is a good way to get continuous rewards for adding value to the entire system IMO.

Thinking out loud, even if it's not Ether (to keep the miners at current levels), but some additional special "maintainer reward token" (MaRT? 😆) that could be traded on the open market, that would go a long way. Ether is probably the preferable way rather than adding a new core platform incentive mechanism, but hey, whatever works 😉

DAO-based models [and] Further Reading

A thousand times yes.

You've probably seen this already, but I'd like to toss a Nadia Eghbal post on decentralized funding into the discussion.

i was treating this issue as a ERC (which i understand stands for Ethereum Request for Comment), not an actual EIP (Improvement Proposal).

Yeah, it's super confusing. ERCs are a subtype of EIPs (EIP > Standards Track > ERC). They have a particular format, defined here (example ERC). The name "ERC" is modeled after "RFC"—both of which are misnomers from how they're actually used IMHO.

This is probably not ready to be codified as an EIP yet, and when it is it probably belongs as a "Core" EIP when there's enough technical detail (example Core EIP). A lot of the material here is what would need to go into that format eventually, so we could get this into an EIP format, and plug away at the technical details. More than happy to help get this into a format.

I very much appreciate the conversation starting, regardless of what it's labelled as 💯👍👍👍

@bmann

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

@owocki If you have a repo already, great. I can shut mine down ;)

It’s not an ERC either. You need to actually make a PR in the specified Markdown template. This is “just an issue” at this point.

If you use your repo with a README and make a Markdown doc following the EIP template, then you can manage changes and PRs in your own repo AND have any PRs you do to this repo reflect the source changes. Hope that makes sense.

I’m working on improving and documenting the EIP/ERC process, so I’m trying to help jump in and explain. More docs coming.

This is the only thing close to a community wide governance channel we have, so assigning a number to it is great.

@MadeofTin

This comment has been minimized.

Copy link

commented Mar 11, 2019

@bmann I'd like to get this pushed through so signalling can start on Tennagraph. Is there an EIP format that works existing? perhaps meta? I understand this is in a state not yet to be "codified as an EIP" , but that poses a problem in the case where signalling is exactly what we need to progress it.

I want to approach this direction before building a separate system for signaling on these kinds of issues.

@bmann

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

@MadeofTin there are no blockers for @owocki to make a PR that just puts this into Markdown, where it will then be a Draft. That’s what will make it an EIP.

@owocki

This comment has been minimized.

Copy link
Author

commented Mar 11, 2019

@MadeofTin there are no blockers for @owocki to make a PR that just puts this into Markdown, where it will then be a Draft. That’s what will make it an EIP.

its on my TODO list this week :) thank you @bmann @corollari for the coaching so far!

note that this issue is meant primarily to create discussion, and to lay out a case. ideally tennagraph would be able to get signal on each of the following pieces discretely @MadeofTin

  1. Why ecosystem stewardship is important
  2. Why ecosystem stewardship cannot be properly funded without inflation
  3. Administration of funds / Tuning of parameters

is that possible?

@MadeofTin

This comment has been minimized.

Copy link

commented Mar 13, 2019

  1. Why ecosystem stewardship is important
  2. Why ecosystem stewardship cannot be properly funded without inflation
  3. Administration of funds / Tuning of parameters

is that possible?

Definitely possible. I am a little confused on how to approach the second explicitly, but I think there is a way to get there. What are your thought on how the modules would be set up? @owocki

Overall, I have been reading over the recent discourse and recommend implementing 3 different voting modules to be effective.

  • Establish Ecosystem Support (Vote Yay, Nay, Abstain) Mutually exclusive
  • Vote on the mechanism (Mutually exclusive)
  • Vote on different policies distribution and others (Can vote for multiple)

I wrote up a visual example as a starting point for discussion.

image

@owocki

This comment has been minimized.

Copy link
Author

commented Mar 13, 2019

this makes sense at a high level to me. i appreciate all the thought going into this! let me circle up with a few people in the working group

at first glance, one thing that we'll need to do is further bake the inflation funding proposal (there are different flavors of what could/should be implemented based upon how we design the body that maintains those funds)

@MadeofTin

This comment has been minimized.

Copy link

commented Mar 14, 2019

Another option would be to release each module separately. Something like module 1 then a week later release 2 and then a week after that release 3.

And, just to be clear, creating custom modules isn't a feature supported on Tennagraph right now, but all of the tech to make it happen is there for someone to put together. So, either someone from your team could submit a pull request and we can launch or we can raise some funds for the Dev team to work on this piece.

@MadeofTin

This comment has been minimized.

Copy link

commented Mar 14, 2019

this makes sense at a high level to me. i appreciate all the thought going into this! let me circle up with a few people in the working group

Is there a channel I can join to join the discussion? We have a bridged telegram https://t.me/tennagraph and riot group https://riot.tennagraph.com would be a good place to discuss

@owocki

This comment has been minimized.

Copy link
Author

commented Mar 14, 2019

hey @MadeofTin checkout the links at the bottom of this medium draft for links to our telegram group

@jpitts

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

RE: the points of process brought up by @bmann and @expede, I agree with these points.

@owocki, what this EIP should be classified as is an "Informational EIP", as defined in the EIP-1 Types.

EIP-1789 as an Informational EIP can form the philosophical basis, design principles, and requirements for a system to provide stable funding for Open Source projects in the community.

As EIP-1789 matures, it can be referenced in a future Core EIP defining the inflation funding mechanism in the protocol, and subsequent ERCs which would define the mechanisms of fund distribution. Also, critically, it would be referenced in a Meta EIP which would define the process for managing such a system.

EIP-1789 is the overarching philosophy which will drive a number of proposals. It can then evolve, enabling the dependent proposals to evolve along with it.

@owocki

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

thanks @jpitts -- agree RE: points of process; we are planning on submitting the formal EIP within the next day or two

@jpitts

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

Thanks for the updates; are there certain Issues that I should look at that will have more bearing on this formal EIP?

@owocki

This comment has been minimized.

Copy link
Author

commented Apr 1, 2019

I am closing this issue as, per noted above, it does not follow the EIP process. For further discussion on this topic, I recommend those reading this checkout the telegram group and also #1890

@owocki owocki closed this Apr 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.