Disclaimer: I support the developer payment poll. I have voted Yes.
Introduction
Let's start with two base-level statements that I think everyone can agree with:
Funding of an organization, from an elementary school recycling club to a top level corporation, is critical to the continued operation of that organization.
Gridcoin core devs are amazing and deserve to be paid from the foundation funds.
That said, there has been no shortage of concern expressed around the currently running developer compensation poll.
Summaries
Here is a bullet point summary of the reimbursement process and proposal for those who are not familiar:
- In July 2017, Rob proposed a developer reimbursement plan at $30/hour.
- The proposal defined a 6 month period before being reevaluated.
- The first payment was for August dev work.
- On March 2nd, Rob proposed increasing dev payment to $60/hour.
- Rob is the person who determines if work deserves reimbursement.
- The thread of the conversation for both proposals along with the reimbursement summaries can be found here.
Here are the main concerns and questions I have seen expressed:
- The proposed increase in funding was not explained well enough.
- $60/hr is too much for dev work.
- Who determines what work is worth pay and how long a job should take?
Here is a summary of the first 6 month block expenses:
- 1605.5 hrs spent on development
- $48,165 paid for development
- 411,945 GRC paid for development
- Average price works out to $0.11/GRC
Note: I did the work by hand and may have missed some invoices or miscalculated.
Note: These figures do not include reimbursements for adwords, Netsoft, or the newbie stake.
Here are some straight forward problems that I noticed with the first 6 month block:
Invoices are not standardized and are difficult to read.
Some people did not submit their development hours at the end of the month, which means they can wait until the USD/GRC price drops before getting paid in GRC, meaning they get more GRC. (Though I'm not certain if this is factored into how Rob released funds).
GRC was paid for developments that were developed privately and ultimately not implemented.
Here are some straight forward solutions to these problems:
Create a standardized invoice form and a separate thread for posting only reimbursement data. If a dev does not use the standardized invoice form, they cannot receive reimbursement for those hours.
State that work data is due by the 7th day of the following month. This means that if I work in April, I must submit my hours by May 7th. If I do not, I cannot receive reimbursement for April.
State that only work for implemented developments will be reimbursed. This will encourage people to keep the community up to date with regards to what they are working on so they can receive feedback on the likelihood of their developments being implemented. It will also encourage community contributions during development, which I will discuss later in this post.
Addressing the Concerns with the New Proposal
I think the concerns can be broken down into three general categories:
- Communication
- Pay level
- Logistics and operation
Communication
Communication is critical.
Personally, I share this concern -- there was not enough discussion around the previous 6 month block and around the reasoning for a pay increase. None of the concerns from the first 6 months block proposal were addressed with the second proposal. None of the questions asked in February were addressed before the creation of a poll for a pay increase. In fact, the 6 month period ended at the end of January, but the new proposal didn't come out until the beginning of March. I am willing to accept that this was due to forkapalooza, but there was no communication, so I cannot be sure that it wasn't due to poor management.
I truly hope that communication improves before the next 6 month block, if that is the route we take. One way to do this is to start the discussion 1-2 months before the end of the 6 month block.
Additionally, the poll and proposal itself is... lacking. What did we do? Why are we doing what we're doing? What will we do in the future? What happens if this raise is rejected? Do we not pay developers? Do we maintain $30 an hour?
The presentation does not inspire confidence.
Pay Level
Personally, I think $60/hr is appropriate. I do, however, understand people's concern that this is too much. I think that it is important to consider how competitive the blockchain space is, that GRC does not provide benefits, and that we are asking for people to contribute time outside of their day(or night) job.
I do not think that unimplemented developments should be reimbursed at $60/hr, or at all. This is a major concern of mine.
Logistics and Operation
I agree that the current reimbursement structure cannot continue for much longer.
Here is what I said in July when the initial proposal was put forward:
I am grateful that reimbursing and paying devs is a top priority of GRC. This demonstrates that development is progressing and that this progression is going to continue. It also shows that the volunteer work of the community does not go unnoticed and is highly valued.
My concerns regarding this proposal stem from the fear of this payment system becoming precedent for future payments:
This is a highly centralized proposal. This means that the random work Rob mentioned that needs to get done can get done quickly. This also means that work is judged and compensated at the whim of a single entity (as respected and trusted as that entity might be -- this is not directed at Rob, but at the system) instead of by consensus among the greater community. So long as we do not use Rob's benevolence regarding this payment block to influence the conversation regarding future compensation, I can see myself supporting this proposal in time.
I stand by this statement.
I and others have proposed alternatives and begun discussions around how we might move forward.
Moving Forward
We need to change how we fund development. In the meantime, we need to fund development. I suggest that we accept Rob's payment proposal and use the 6 months to develop a new budget structure while working toward the ultimate goal of a complete treasury system.
The discussion has already begun. You are invited to contribute:
A Gridcoin Budget (v0.2)
A Gridcoin Treasury - Working Draft
A Gridcoin Bounty Bot
Now that the white paper is out for a vote, I will be spending more time working on the budget (among other things).
Here is what I am thinking of working on for v0.3.
First, change the dates to propose that the budget begins after the next 6 month period.
Next, integrate the following ideas into the proposal.
An organization can be broken into three pillars:
- Engineering - Building
- Management - Organizing and communication
- Marketing - Spreading the product
Each of these pillars can be broken into sub-structures. For example:
- Engineering
- Core maintenance
- Core development
- Potential Improvements
- UX/UI
- Management
- Management
- Project
- Financial
- Legal
- Support
- Marketing
- Branding
- Advertising
- Outreach
- Partnership
- Management
Each of these structures and sub-structures needs funding. There are many different ways to fund these jobs.
I would suggest that core maintenance and development is the only work that should have an hourly rate. So what are the alternatives?
Community Funding
This is a commonly used means of funding development. An individual develops something openly while advertising a donation address. If their endeavor is supported, they will receive donations. If it is not supported, they will not receive donations. If they do not receive donations, they will either continue working on their project for free, stop work on the project, or work to make it so the community supports it. It is based on the principal that money talks -- if your idea is supported, people will pay you as you show progress.
A way to implement this in a protocol is roughly outlined in the treasury thread.
Bounty Funding
A bounty is made for the completion of a task or a solution to a problem. The bounty value rises if people think the product the bounty seeks to incentivize is important. When the "demand" for the product reaches equilibrium with the community's "supply" of people willing and able to build the product, someone usually takes up the task. Upon submission of a product which meets the bounty's contract terms, funds are delivered. There are some challenges involved with a bounty system which revolve mainly around contracts that are not well written or clearly defined. These challenges can be overcome, but that requires work.
Bounty systems can be fairly cut-throat if contracts do not demand communication. What if two people are separately working on solutions at the same time, but they are not communicating. Only one of them will receive the bounty which means that the other just put in X hours of work for nothing.
Bounties require people put serious work into building contracts. Not many people like doing this type of work.
A way to implement this in a protocol is roughly outlined in the treasury thread.
Foundation Matching/Funding via Proposal and Poll
Foundation matching works with both community funding and bounty funding. An individual or group completes a product and either claims a bounty or receives donations. They then create a poll asking for further reimbursement from the foundation funds based on the bounty, on how much people donated, or on some other definition outlined in the payment proposal. This would require strict definitions on what makes a poll requesting funds from the foundation valid. There are currently loose parameters, but no clearly defined and advertised definitions.
A way to implement this in a protocol is roughly outlined in the treasury thread.
Elected Management Responsibilities
The community elects an individual or group of individuals to manage resources for each of the three pillars. A set amount of resources is allocated to each pillar for a set amount of time through the budget proposal. The responsible individuals are reelected at the end of every budget term.
Until there is a treasury system, this is the most straight forward possibility when it comes to funding tasks that require funding. It is less centralized than the current system run by one person, but still centralized into a "representative board". The budget v0.2, for example, suggests Ravon and Caraka be in charge, or named to the "representative board of development" which would be responsible for managing funds allocated to development. This board could be expanded on. The proposal also suggests forming a "representative board of outreach" to manage funds allocated to outreach endeavors.
I will likely be expanding on this possibility in v0.3
A Treasury System
Being able to build a treasury system in a code-based protocol that directly interacts with the minting of a currency is a very significant use-case of blockchain technology and cryptocurrency. A treasury system is a means to collect, allocate, and release funds. They are highly structured. We are not ready for one yet, however it should be in the back of everyone's minds -- how can we put funding practices into a protocol?
Conclusion
We have a lot of work to do before we are ready to implement some sort of funding structure that is different than the one currently in place. Please contribute to the discussion and construction process! In the meantime, let's be vigilant and watch who gets paid for what, and let's support developers and community members as they work to make Gridcoin what we all know it can be.