Presently there is an expectation (established by motion) that expenditures on NuBit core development should average approximately 10,000 NBT monthly. The past several months spending on NuBit development has been far below the target, probably just over 2,000 monthly.
I will remind everyone that I haven’t been receiving any compensation from NuBits for over 6 months so that I can focus on B&C Exchange. As such, I don’t have any responsibilities to deliver releases for NuBits. However, I am happy to facilitate them so long as it doesn’t distract from the higher priority task of implementing B&C Exchange.
It is clear that core development for NuBits needs an additional developer. Several months ago sigmike and woodstockmerkle were working on the 2.1 release. Mike has had less time than expected to work on either project, but what time he has had has been devoted mostly to B&C recently. Woodstockmerkle has dutifully worked on the difficult 2.1 release in addition to other full time responsibilities. The 2.1 release has taken much longer than anyone expected. I had a conversation with woodstockmerkle where we agreed that we should spin up development on the separate NSR re-denomination release (which shouldn’t be too difficult to complete) so that we have different people working simultaneously on each release. Whichever gets done first gets released first, but the NSR re-denomination would be based on 2.0.3 code. This way we aren’t stuck waiting on the difficult 2.1 release (which contains only performance optimizations) any longer.
The question is who will code the NSR re-denomination and other releases we have planned? Sigmike can’t do it. Woodstockmerkle needs to stay focused on 2.1. So, we need to find another developer. I considered hiring a developer about half time to do NuBit development. Good developers are hard to get half time. They tend to have full time jobs, so we either have to be that full time job or we have to be the moonlighting job they do in addition to another full time job. There is a lot that is attractive about finding someone to work on it full time. Where we are about 25,000 to 30,000 NBT short of our spending target right now and the projection is we will have an extra 7,000 or so each month in coming months that is unspent if no additional developer is added, it means there are enough funds to hire a full time developer dedicated to NuBit development for six months. Even though such an expenditure is within the established spending plan, shareholders should keep in mind that it will still put additional pressure on the peg versus not hiring an additional developer. Doing less development and saving money is an option that should be considered.
Another variation on hiring a new developer that can be explored is to have them commit to delivering certain features features for a fixed fee.
Regardless of the compensation model for developers, it is clear to that the current structure of them essentially reporting to me is suboptimal. Let me explain. When someone works physically present at an office 5 days a week you can have considerable confidence about how many how will be worked. When you have contractors who work off site, have other professional obligations and who have pledged to work 20 or 30 hours a week on one of our projects, the risks of not getting that labour rise considerably. What I found is that developers sometimes fail to keep these time commitments. When this happens, they tend to be shielded from disapproval from the community because the agreement was a private one between me and them. Instead, I become the target for that disapproval. A structure where I am held responsible for developers not putting in their hours is dysfunctional. The responsibility needs to reside with the developer who has commited the time. Let the glory or shame be theirs. I don’t have much control in the situation.
So, I want to be very clear about not taking any responsibility for NuBit deliverables. That should be the responsibility of a specific developer, primarily. The community should be very clear about whose responsibility it is. I am, however, willing to participate in the selection and vetting of developers. I am also happy to engage in conversations about implementation details with developers. I am happy to review invoices and payment of invoices as Angela pays them. However, any agreements developers make to do work need to be with shareholders, not me.
While I will remind everyone again that I won’t take any responsibility for what a developer delivers, it seems likely that we could get all or nearly all NuBit development currently mandated by motion completed with 6 months of full time work. This includes NSR redenomination, 2.1 optimizations, new currencies, removing share days destroyed and volume dependent transactions.
As an aside, I am quite concerned about our capacity to introduce 3 currencies at once. There aren’t any serious issues with this in regard to core development. The problem is that we will have trouble properly supporting 4 currencies with low spread and deep liquidity. We could do it, but it might cost too much. Doing a poor job of supporting these currencies could ruin their market acceptance permanently, so we need to be careful to not to over commit. I think only releasing Chinese NuBits at first is prudent. We could release the client such that it is ready to support European and SDR NuBits without a code change. I think the expense of this development can be justified with the expected sale of Chinese NuBits alone.
We may even be able to get volume dependent transaction fees implemented with 6 months full time work, although there are no formal and defined plans to do so at this point. There is a passed motion stating it should be a “high development priority” which encourages a motion estimating the cost of implementation.
So, to summarize, we have three choices:
- Save money on core development by spending less than 10,000 NBT per month and accepting a slower release pace.
- Hire a full time or part time developer who is paid hourly.
- Hire a full time or part time developer who is paid a flat fee per feature delivered.
My guess is that hiring a full time developer for six months who is paid hourly is the most prudent path. What does everyone else think is the best way to proceed?