Gridcoin currently has a payment system intended to compensate developers for time spent and to give an incentive for new developers to join the project. While I agree that the reasons were noble, with the current bank of 31.6 million GRC and the current price of $0.0044/GRC we risk burning the funds faster than we anticipated. In December 2018 we paid 496,126.34 GRC in developer compensation and we haven't started paying for @vortac's marketing expenses. While not drastic, at the current rate expenses will start to pile up.

In the Gridcoin Community Hangout #92 I talked a bit about changing the developer compensation from $60/h to a flat 1000 GRC/h. At the time I didn't think it was necessary to go through the whole network poll process as it's a decrease in expenses until the Gridcoin price increases by 13x, so I figured an internal Slack poll with the affected developers would be sufficient and bypassing a foundation poll would allow us to move more swiftly (for a change). I received some objections to this approach so we will do a network poll.

Regardless, I wanted to explain my rationale behind the initiation as it may not be clear what its benefits and downsides are. I know that most of my points are moot when I could just charge 1000 GRC/h instead of $60/h myself, but this affects all of the paid developers. We might need to change our approach unless the GRC/USD rate picks up speed.

TL;DR: Changing the payment scheme from USD/h to GRC/h would provide more benefits than downsides while reducing expenses. However, we will run a network poll and the change is not in effect.

Changes

The change I propose comes with both pros and cons.

Pros

• Predictable budget
• Self value
• Easier bounty pricings
• Longer lasting foundation funds
• No need for hidden hours
• Dedicated time
• Extended funding

Cons

• Lower hourly payments
• Less attractive for new developers
• Needs new guidelines

Let's go through them all, starting with the pros. Note that these assume the current GRC/USD price or lower. If we got back to ATH
most of these don't apply.

Pros

Predictable budget

Since the current system is tied to whatever GRC is valued at we have no idea what our expenses are going to be. We can guestimate the number of hours people are going to spend but what that translates to in GRC is only known at the time of the payments. Disconnecting from USD allows us to get a better feel on where we are going.

Self value

This one I have a hard time to explain, but one benefit of detaching payments from USD is that it focuses the value on the GRCs and Gridcoin itself. It moves away from "How much is my time worth now?" with its implied intent to develop to sell and instead puts an, albeit arbitrary, developer belief in the project. "How much can I make this coin grow?" if you will.

Now, I know this change doesn't contradict what you could already do with the current system. The receiver is free to do what he or she wants with the received payments, including saving them for future growth. However, I still believe it might alter the mindset if the coin is more self contained.

Easier bounty pricings

Right now there's a huge disconnect between bounties and hourly payments. A good example of this is implementation of the UI redesign bounty which sits at around 100,000 GRC. I put up a rough effort estimation of 160 hours, or 1 man month, which is in the same ballpark as the bounty at "100 hours" given a 1k/h payment. In contrast, with the current price of $0.00438205 we are looking at an expense of 1.75 million GRC if were to hire a contractor.

If we see the bounties as bonus to regular work then they are only attractive for the current developers. While a change in the dev payments doesn't affect the external attractiveness of the bounties themselves, it will be much easier to estimate the required effort to solve a task and, by extension, estimate what the size of a bounty should be. It can also be realistically paid for from the foundation without having to rely on user donations.

Longer lasting foundation funds

Self explanatory, I assume, but it ties in to the subsequent pros. With a lower burn rate we have more options.

No need for hidden hours

I know we have said this many, many times before; Our developers underreport hours spent. For example, @jamescowens has over 100 hours not billed for while working on the scraper. I want this to change to make it more visible what the developers do. We should not undercharge to stop draining the funds. We should take pride in time spent.

Dedicated time

Last year I had the opportunity to take Fridays off from work and focus a whole day on Gridcoin development. This allowed me to focus on tasks for longer periods at a time and had an amazing impact on productivity. While that option is still available for me it comes at the cost of over 400.000 GRC per month, not counting the stray work. This adds up to 5.2 million, or 16% yearly, of the current funds.

Extended funding

Lowering the payments and extending the life of the funding pool allows us to explore compensations for other areas. Why should only the wallet developers receive compensation when we have translators, web designers, show hosts, package maintainers etc? All of these are needed for a functioning ecosystem, yet a small minority receives compensation.

Cons

Lower hourly payments

This would be a massive blow to income of those working with the wallet right now. It means going from $60/h to $4.4/h with the risk of going even lower. This is detrimental for developers who rely on this income stream.

Less attractive for new developers

Developers seeking an income will instantly turn our project down as no software engineer would work for $4.4/h as their main job. It may be a deterrent but seeing as the compensation has attracted 0 new developers since its launch this might not matter. We can state for a fact that after such a change it would definitely attract 0 new developers who are only in it for the income.

Needs new guidelines

This will require new guidelines on what to do when the coin drops or rockets. Do we need to adjust the rates on up- or down trends to better match the size of future rebounds? Or should we stick with what we have? There are probably more questions which would need to be fleshed out and thought through.