State of NuBit core development and options to proceed

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:

  1. Save money on core development by spending less than 10,000 NBT per month and accepting a slower release pace.
  2. Hire a full time or part time developer who is paid hourly.
  3. 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?


I believe this is the best path.
We need to constantly improve Nu.
I think finding a full time developer is much better than a part time developer. Concentration is key.
Full time commitment produces much better results.

I would be more than happy to use my recruiting skills here too, to find the best developer for Nu, as I could help in regard to BCE with @Eleven .

Would shareholders be ok with a referral fee here too ?

1 Like


I agree with @cryptog here and @JordanLee
We need the developer:

  • to be committed on the long run
  • to be paid “on the result”
  • to be financially motivated to continue the work as a real daily job.

This thus appears the most reasonable, imho.

I’m in favour of one of these options.
If I had to choose between a full time developer for 6 months and a part time developer for an unforeseen future, I’d rather have the part time version.

I’m no developer, but I suppose getting used to code, really knowing it can take time. This is an effort that pays out, because it increases the understanding of the code and both the speed and the quality of the coding.
For that reason I’d rather have a part time devloper stick around, maybe with a variable amount of hours/tasks being contributed to respect his/her time and the need of Nu.

Imagine there’s a bug that needs to be fixed. Would you rather have a had a full time developer whose contract unfortunately already ended or a part time developer who can focus on that?

I’m on the fence whether hourly or flat fee payment is better.
Hourly payment can look like a waste of money, if a feature takes longer than expected. But sometimes it’s more difficult than it may appear to be.
Flat fee payment on the other hand can lead to worse quality, because the focus is on getting it done as fast as possible while just keeping the thresholds that are used to measure whether the task was successfully accomplished or not.
Mixing the both to get the best of both worlds makes it even more complicated.

I don’t feel comfortable making a choice between hourly payment and flat fee payment, but have a strong preference for a part time developer.

I know how difficult it is to get a good developer for just a job or part-time. They usually prefer full-time, focussed jobs.
As a Shareholder I would prefer a part-time developer for the reason MoD already mentioned, you can spread the work conveniently, lower burn rate and ability to possibly built a longer engagement than with a full-time developer for just 6 months.

I’m a fan of fixed price as long as the requirements are stable and clearly written. It appears to me that this is not always the case with Nu, the question is can we change that? This requires an effort from those representing the community in translating required functionality and priorities into well-defined and specified jobs.

When that can be done, the only question remaining is do we want to burn all the development money in 6 months or spread it out more resulting in slower delivery of new releases. Given the current state I tend to slow down a bit on the development side. Popular belief for startups is however contrary and we should gear up development as that would attract marketing opportunities and new customers = profit.

I recommend to hire developer for 6 months and spend some time in advance to clearly write out what jobs and their priority needs to be done or finished and have the developer make some estimates about what can be done within those 6 months and publish that for review in the forum.

We need visbility of who is responsible for what. [quote=“JordanLee, post:1, topic:3958”]
to have them commit to delivering certain features features for a fixed fee.

This is good.

Fine with me.

Totally agree. Many of the wishes by shareholders had no cost estimate from the devs. I suspect we are asking more than we can afford.


I am in too, to begin recruiting, provided the search for the dev is determined and the referral fee is determined.
The search for B&C Ex senior C++ devs rewarded in contingency 10% of the total compensation.
The fee for that NuBits core dev search should be determined according to the urgency and difficulty, imho

1 Like