The 253rd "Thoughts on developer funding" Article

0 5
Avatar for cpacia
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

Generally I try to stay out of community drama and I know another "here's my thoughts on the funding proposal" article is really pushing it, but I will weigh in anyway. The point here is to mostly point out what seem to be serious misconceptions in the community about how software development works.

Developers must submit an itemized list of things they intend to work on and the number of hours it will take to complete each item.

By and large this isn't how software development works. It seems like many people are under the impression that software is just "write once and forget". Software is rarely ever "done" in any meaningful sense. Instead it requires continual, on-going maintenance to keep functioning. For a large, complex codebase like full node software this includes bug triage and fixing, refactoring, optimizations, improving test coverage, paying down technical debt, backporting, code review, and documentation. Code review usually being the biggest bottleneck. Especially in a codebase where if you fat finger one line of code you can blow up the whole system.

This generally isn't the type of work you create an itemized list and bill for. For example, bugs come up all the time that are unexpected and not planned for. Libraries you are using publish new versions that require updating, often necessitating changes to the code to conform to a new interface. If you set out to improve test coverage you may end up finding that several modules need to be refactored before you can even begin to write more tests, etc, etc etc.

In a thread on Reddit one user wrote that for every $1 in development a company usually spends $4 in maintenance. Not sure how accurate that is, but you get the general point.

When discussing funding development people seem to be under the impression that the money will go to adding new features which you can track progress towards. While this will account for part of it, most likely 80-90% will just go to general maintenance. People saying that developers asking for money for this are asking for a "slush fund" or viewing the need for code maintenance with extreme skepticism as if we're just making this up to get free money, is actually borderline offensive.

This isn't to say development teams are under no obligation to say what the funds will be put towards. Last year I published the BCHD 2019 feature roadmap primarily so that people who are contributing donations or development time would know what to expect. Note that we only completed 4/9 items on the roadmap due to lack of time. But even there, most of our time was spent on just maintenance of the codebase, not features.

Scaling the software requires more developers

Bitcoin Core has something 12-15 full time equivalent developers (this is just a rough guess by eyeballing github). By backporting commits from Core, a codebase like ABC can effectively get another 12-15 full time developers for free. Or at least almost free as the commits still need to be rigorously reviewed and merge conflicts dealt with.

But this is clearly not a viable long term strategy if we want to scale the network as Core has no plans on making the changes to their software necessary to scale. At some point the software needs to diverge substantially from Core, but that can't happen as long as ABC only has like 3-4 devs working on it. The more the codebase diverges, the less code can be backported and we lose many hours of free development.

To be able to scale the software without worrying about diverging too much from Core requires creating a team of developers that would rival Core's in terms of numbers and quality.

Last Year's Fundraiser

I'm hearing a lot of people asking what was wrong with last year's fundraiser. Or more specifically, what is wrong with voluntary donations? Don't get me wrong, I'm personally grateful to everyone who contributed, but there are limits to how much you can expect to get from a fundraiser.

For example, few people might remember but the fundraiser was initially pitched as just a "down payment" with the idea that we might need to do these type of fundraisers more frequently. The 800 BCH goal would likely only be enough to pay two full time developers for a year. Maybe even less than two.

If that fundraiser were run quarterly I think we would maybe get close to the ballpark of what is needed, but my impression is we likely got everything we were going to get from the community at that point and turning around and starting another fundraiser right as this one ended likely would not have been well received. And personally, I think it's unreasonable to ask average redditors to cough up hundreds of dollars per quarter to keep the lights on.

This also says nothing of the uncertainty developers experience wondering if the fundraiser is going to be enough for them to pay their bills or if they are going to have to dip into their retirement savings to pay rent. Or if they should start looking for a another job. Remember many people who work on these projects often make much less than they would working in Silicon Valley for some large tech company. They do it because they believe in Bitcoin Cash's mission and genuinely want to see it succeed.

Very unhealthy dynamics with Bitcoin Unlimited

A long time ago, well before the Cash-Core split, Bitcoin Unlimited received a large anonymous donation to help Bitcoin Unlimited win the scaling battle on BTC. That battle was obviously not won and we had to fork off.

But in the intervening years the Bitcoin price has increased dramatically and they now sit on a war chest of something like $6M. Combine this with a very low burn rate and this creates an incentive to oppose and try to block attempts to fund other development teams as they would be lone group remaining if everyone else packed up and left.

Bootstrapping the network

Imagine if Satoshi released Bitcoin without a miner subsidy. After several years of operation it became clear that not enough people were transacting on the network and the transaction fees that were supposed to be used to secure the network were woefully inadequate. Further imagine that some people proposed creating coins out of this air and using them to pay miners to secure the network in the early days until transaction volume was large enough to sustain the network exclusively with fees. What do you think the reaction of the community would be?

Judging by the reaction of many people in the BCH community I would expect a number of people to freak out, rage quit, and/or threaten to fork the network.

We didn't have to go through this because Satoshi had the foresight to include this subsidy from the beginning. But it's pretty clear that Satoshi didn't have a similar plan for financing development during the bootstrap phase. Did he plan to stay around as lead maintainer forever? Did he plan on using his 1M coins to partially finance development? Did he assume the early developers would get rich enough from early participation that developers could self finance themselves? It's not clear but, of course, none of that happened.

Using part of the miner reward to finance development while the network is bootstapping seems like a reasonable extension of the original concept. The subsidy should not be permanent as at some point one would expect that if the network gets big enough there will be enough large businesses making donations that development would be adequately funded. In fact the current proposal limits it to only six months.

People rightfully have concerns about who is holding the money and how it is to be distributed. Some of the proposals to ameliorate the problem have been pretty decent. But the general opposition, if not outright hostility, to developer financing seems very misguided to me.

Show me an alternative financing proposal that has an equally realistic chance of success and I'll seriously consider it. But I haven't seen anything other general hostility and suspicion of the developers.




1
$ 0.00
Avatar for cpacia
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

Comments

Thank you for standing up for the developers in BCH. I don't even understand where you guys make your money, I honestly don't get how you guys can afford to do anything at all with the lack of regular income.

$ 0.10
4 years ago

If BCH devs invest in BCH and work hard to make BCH better than BTC - BCH price can surpass BTC price which means that $20k saved in BCH could be worth $500k in a year or three.

On the other hand, BCH devs could also make a more rational decision to save in both BTC and BCH (and other coins).

EDIT: I support every funding including the miners' proposal.

$ 0.00
4 years ago

Show me an alternative financing proposal that has an equally realistic chance of success

Chance of success to do what? Who defined what success means here?

Using part of the miner reward to finance development while the network is bootstapping seems like a reasonable extension of the original concept.

It obviously does not seem like a reasonable extension to "half" the community. And if it is a reasonable extension in your opinion, hard-fork it, don't force those that don't agree with you to come with you.

But in the intervening years the Bitcoin price has increased dramatically and they now sit on a war chest of something like $6M. Combine this with a very low burn rate and this creates an incentive to oppose and try to block attempts to fund other development teams as they would be lone group remaining if everyone else packed up and left.

Cheap. We could as well accuse the developers in support of the plan by implying that they are supporting it only because it means a salary for them and it would an equally speculative accusation that doesn't help anyone. Also, if I am not mistaken, BU proposed a way to stop the soft-fork a day or two after the actual backlash from users. I get really annoyed by both sides trying to discredit important people that have given a lot to the community over this.

$ 1.10
4 years ago

Rather than some nebulous infrastructure fund, I propose projects that consider themselves as infrastructure, offer service contracts to the (professional) users of their software.

Will gladly debate.

https://twitter.com/btcfork/status/1222247290766753795

$ 2.02
User's avatar btcfork
This user is who they claim to be.
We have manually verified this user via some other channel.
4 years ago

Thanks for your great post. IMO, you give the people posting attacks (on miners rewards going to developers) the benefit of the doubt (on their good intentions) and then seem a little surprised they say bad stuff based on faulty assumptions. Many real people are posting with good intentions, but, there is a massive anti-BCH and anti-forced-donating-to-BCH element using devious and dishonest methods to steer the discussions in toxic directions. I have never seen so much effort on the part of the BTC-troll army and their allies. There were real issues about the plan that needed figuring out and they love uncertainty. By assuming terrible and unlikely scenarios will happen, they capture vulnerable community members into webs of lies. They smelled blood in the water and hoped they could use this to divide the real BCH community by pretending they were a big part of it. They had better constructed false narratives than I have seen previously as their agents are getting better at it or they brought in their best people for this attack. I guess my point is that the developer-disrespectful part may be something that was created and encouraged by professionals looking to make developers feel unloved by fanning the flames of every little concern they could find.

I was sad to see mr Rizun (BU) join in the attack with a long complex article that seemed technically true but of no real importance I could see. It did seem to imply something terrible, but, without a real problem. Maybe I just failed to understand. I am concerned BU may have strings attached to it's funding that are anti-BCH. That would explain their investment strategy.

$ 0.10
4 years ago

I guess my point is that the developer-disrespectful part may be something that was created and encouraged by professionals looking to make developers feel unloved by fanning the flames of every little concern they could find.

This might actually be true.

$ 0.01
4 years ago

Even a broken clock is correct every now and then, lol.

$ 0.00
4 years ago

But who is arguing that infrastructure doesn't require maintenance? Obviously having an itemized list includes the expectation of maintenance. If it requires more work, then track it and tell the person who's paying the bill what you've been working on.

Nobody (relevant) believes that features are just added and then magically work without maintenance. We just need accurate estimates for the costs involved. Nobody buying a Ferrari is going to be surprised when their maintenance costs are high.

Employees still need to communicate what they've been working on, even if it's non-exciting bug squashing and general maintenance. If people want to get paid to work on this project, they need to treat it as employment.

$ 16.71
4 years ago

Further imagine that some people proposed creating coins out of this air and using them to pay miners to secure the network in the early days until transaction volume was large enough to sustain the network exclusively with fees. What do you think the reaction of the community would be?

The difference between this and the current proposal is that the latter is arbitrary. Why should one development team be rewarded and not the other? This would create an environment of resentment and hostility inside the community. This is what we are seeing right now: anonymous small devs are against the proposal and established ones are in favor of it.

Yes the donation model is not perfect and less stable, but it is far healthier for Bitcoin Cash IMO.

Thank you for posting, and thank you for what you are doing with BCHD.

$ 0.11
4 years ago

J-Stodd thanks. For me personally I get paid to work on OpenBazaar full time and I'm lucky enough that they don't complain if I spend some of my time working on BCHD as a side project.

I'm not sure how much longer I'll be with OpenBazaar, however.

$ 0.11
User's avatar cpacia
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

BTW where does OpenBazaar gets money from? There are no fees as far as I know on OB.

$ 0.00
4 years ago

Just burning VC money.

$ 0.15
User's avatar cpacia
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

Strange.

Doesn't VC operate on some business plan?

Can you share what the plan for OB to get income entailed?

Because it's a great project, it deserves a solid footing.

$ 0.00
User's avatar btcfork
This user is who they claim to be.
We have manually verified this user via some other channel.
4 years ago

Fort the most part the VC's just care about exponential user growth with the view that monetizing those users later would be rather easy.

Likely some form of ad revenue.

$ 0.10
User's avatar cpacia
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

FYI there's a reply link to reply to a particular message.

$ 0.00
4 years ago

Compulsory fees do not work because there is a high risk of tax consequences. Funding must therefore be voluntary. Transparency and an open culture of ideas are essential: 1. Public collection and evaluation of all ideas 2. Directory of all developers including compensation

$ 2.10
4 years ago

It looks like you need some sort of itemisation regardless of the fundraising method. I understand itemisation is challenging for maintenance, but you could at least indicate what you are going to maintain, during what time period, and how many hours you will spend on it. For ABC, backports from Core can also be items. For new features, it would be wise to include maintenance cost for the near future in the implementation price.

Last year's fundraiser indeed completely lacked itemisation. While reaching its goal, it was never made clear what the community would get in return, and the goal was doubled without explanation. I did not see any update of how the funds were used. Donors publicly complain that they never even got a thank you. Donors are mad how poorly these funds were handled and how developers now seek funding through inflation. Also, no assurance contracts were used to return the money if the goal is not reached. Clearly, there is still a lot of room for improvement here.

Asking for donations is always more reasonable than taking donations via inflation. You are taking away user's hashrate because you don't want to ask for user's money.

Bitcoin Unlimited has done a lot wrong, but that doesn't mean that they are doing this wrong too. Your funding proposal should stand on its own merit regardless of BU's opinion. Besides, while BU's organisation structure has often been rightfully criticised, how are you sure this HK corporation's fund allocation is ultimately going to perform any better? My suggestion for the HK corporation to use BU's Articles of Federation as a starting point was only half a joke. And let's be honest, BU may be trying to starve you of funds, but you wouldn't mind BU running out of funds either.

Why did Satoshi include a block subsidy?

This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them.

As you see, securing hashrate during bootstrapping is only one of the reasons. The other is to bootstrap the coin distribution in a provable fair way. This was arguably more important since otherwise Satoshi would immediately own the entire 21M bitcoin. We cannot objectively measure development contributions without central authority. We can objectively measure hashrate contributions, however. Therefore the inflation goes to hashrate and not to developers.

What you see is not hostility to funded development. This is hostility to the proposed fundraising method.

I mentioned a number of suggestions above. However, should these suggestions not work out, I am fully willing to accept a big slowdown in development. This is an often ignored but valid alternative and I would prefer it over mandatory coinbase funding. You and your colleagues are trying to scale and add improvements ahead-of-time on a shoestring budget, but with network growth more funds become available, and a more just-in-time approach is an option.

$ 11.00
4 years ago

"You and your colleagues are trying to scale and add improvements ahead-of-time on a shoestring budget."

As has already been stated many times, certain complex big changes are actually easier to do early on. For example, it is easier to get changes to the way wallets work when there are only 30 different wallets compared to when there are 1,000. A "we will worry about that later approach" might actually hamstring the our ability to make those changes and make the cost of those changes exponentially more expensive.

$ 0.10
4 years ago

Indeed not only the available funding but also the costs of changes can increase over time. This does not necessarily mean that now is the optimal time to implement them.

$ 0.00
4 years ago

It also doesn't mean that it isn't.

$ 0.00
4 years ago

no HK corp, variable amounts, let miners choose which devs, soft orphaning only.

$ 0.00
4 years ago

Welcome, Chris! Thank you for all the work on BCHD - read.cash uses the BCHD node availble at fountainhead.cash.

$ 2.22
4 years ago

Thank you for saying many of the things I felt like saying while reading many of the articles and comments the past days. There is IMHO a clear lack of trust and very little appreciation of the work that has been done by some of the developers over the past almost 3 years. And yes that includes the work done before Bitcoin Cash was announced or split off. Work needed to be ready and offer an alternative path for those that saw that scaling BTC onchain was very unlikely to ever happen. Others continued to walk into the trap that would have left them with no alternatives the moment SW2X predictably failed.

Thank you for stating nothing but truth. And thank you for putting time and effort into adding value to the BCH ecosystem in more ways that one. I wish with all my heart that there soon is sufficient infrastructure development funding available for people like you to continue to do your valuable work and hope BCH does not lose your involvement due to the need to find a job that no longer lets you spend some of your time on BCH.

$ 0.00
4 years ago

Lack of appreciation, if it even exists, has nothing to do with it. I appreciate the developer's work a lot, that doesn't mean I want to force other people to donate to them, nor am I willing to accept soft-forks in a coin that till now cherished hard-forks. Don't try to portray us as mean people who want devs to starve, it only shows that you don't understand why so many people had an issue with the proposal.

$ 0.00
4 years ago

Well, what do you usually do at work? People would still ask you to come up with an estimate to do features X, Y and Z. Managers don't care about the code rot, refactorings, etc.. unless you're at some top 0.1% company that understands these things. So, you just come up with an estimate, you multiply it by about 3 - that leaves some room for unpredictability and some breathing room for refactoring, etc.. That's one way to do it.

Another way would be to just ask for financing for the next 6 months of Y developers. "Here's what we have done in last X months using Y developers: 1).. 2).. 3).. and we have also refactored, improved security, and there was some overhead- updating libraries, merging, etc.. We didn't have time to do these things: .... In about 3 months the last funding ends, so we propose a next round for next 6 months for Y developers. Here's what we plan to do: ..." I think this plan is really possible.

$ 0.31
4 years ago

That's reasonable, but I don't think most of the community has that in mind.

$ 0.10
User's avatar cpacia
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

The ideas for perpetual maintenance funding drives are in the works. Lets hope something practical comes out of that.

$ 0.10
4 years ago

Hi. Thanks for your post and for your work with BCHD and openbazaar!

Contrary to what some might think, software does rot if not maintained as bugs are discovered and unfixed, new problems arise from developments in their environment, and new exploitation tools are revealed. At a minimum, a crew of highly knowledgeable maintainers are needed. We cannot expect them to work for free in a sustainable fashion.

no, this is not your quote. This is verbatim from https://read.cash/@im_uname/assessment-and-proposal-re-the-bitcoin-cash-infrastructure-funding-situation-3e5179fc#

So talking about a

serious misconceptions in the community about how software development works.

seems to be a bit of an unfair generalization at best. At worst you're building a straw-man. I'm pretty certain most of those opposed to that IFP on the table certainly acknowledge the need for developer funding.

$ 5.00
4 years ago

I agreed that maintenance work needs a plan also. Here is an example of a product support and maintenance work:

  1. Scope of works: a) Anything related to the current features that do not work as intended and require a fix b) Security related R&D activities to ensure the network is secured against attack including penetration testing, hotfixes... c) Roadmapped items: minor enhancements or low priority bugs that are not urgently needed d) Some mandatory updates such as OS upgrades (Linux, MacOS, Windows, Raspbian ), API upgrade - similar to Core codebase upgrade, etc....
  2. SLA: All issues in scope will be triaged to a predefined level, e.g. L1 - immediate HF is needed, L2 - fix in next immediate release; L3 - Roadmapped to future releases.
  3. Performance reports - every month or so, there should be a report on how many tickets the team supported/delivered, and number of hours spent on each ticket (new or roadmapped), so this is transparent to all stakeholders on performance of the team
  4. Change requests: if any new feature that is out of the team's capacity AND scope, it must be raised as a change request. There must be a budget raised to fund for new change requests so that the team can add new capacity to support change requests given the expected timeline. This is also included in the performance report as well.

These are just high level, hope this helps.

Cheers,

$ 5.00
4 years ago