Should maidsafe start giving timescales?

This is what I normally do:
Make a rational assessment of how long a project might take, then multiply by the “shit happens” factor of 10.

That way you always end up finishing faster than anticipated… or just about on time.


IIRC remember David saying something like we wont make it to 11 years of development before a live network (or something closely resembling) in response to an article released stating the project has been snailing for a decade. Not sure who but i think @polpolrene or @happybeing caught it and highlighted it. It was fairly recent. Might be right after the maidsafe asia talk given by krishna kumar. Either way I believe that by the end of the year all of us will be knee deep in an imperfect but very intriguing network full of apps and undeniable potential. New devs will feel COMPELLED to flock over and speed up development. We just need data chains first half and the resulting realtime upgrades. That’s it. After which you’ll want to strap into your seats boys and our newest beautiful girl @Sunshine , we’ll be begging for things to slow down for fear of having our brains melt! :scream::v: :grin:


During our engineering course which included computer science, we were told by the compsci profs that whenever giving an estimate for programming to do our best estimate then multiply by 4. Well during my 4 decades it has proven to be more accurate than any other estimating for new programming projects. R&D I’ve found though is more like you say 5 to 10 times.

Mind you engineering projects are a different kettle of fish and in any project I’ve been involved with the estimate for the electronics part is easy and always take the programming estimate and times 4 it.


I think super high level estimates have value. To get investment at bnktothefuture, maidsafe did provide an approximate time line. Something beta quality by the end of the year seemed to be the approximate time line and I am ok with that.

I don’t think people are realistically expecting weeks or months, but quarters or halves are a useful ball park.


We already have a useful and clear if not very detailed road map, regular statements of activity & progress, and recently a really clear explanation of current status and what is happening next. Everyone would like to know the when, but the difficulty of predicting this accurately makes the use of public estimates debatable (see above! :slight_smile:).

An observation: this desire for timescales even though there’s agreement they won’t be accurate, crops up repeatedly - often I think during a hiatus in progress or community testing activity. So maybe this is prompted by the anxiety that understandably arises when not much seems to be going on in terms of features added, new demos to play with etc.

So I wonder if there’s another way of addressing this. Rather than again asking for timescales, debating it, and as has been happening lately, refraining from doing so perhaps it’s something we can recognise as anxiety and look for other ways of addressing.

I remain of the view that inaccurate timescales are not useful to anyone, so bear with me if you disagree with that! :slight_smile: What else would help you?


Lol I don’t think anyone asked for those :stuck_out_tongue:


I don’t mind that innovation is impossible to predict. I think what people want is to have some insight in to what the team think at any given moment in time. We know this will change as development progresses. We understand that it is quite likely that some things that are supposed to take weeks end up taking taking months. I don’t think most people expect to have timescales that are accurate, but we want to know what they know. If they currently think a certain job will only take a couple of weeks then it would be cool to know that, even though we might all be as disappointed as each other when it turns out to take a few months.

However, experience has taught the Maidsafe boys some hard lessons. I can see why they don’t want to put themselves in that position. It creates more problems than it solves from their perspective. What we need is SAFE working in the wild, not a team potentially distracted by the inevitable consequences of giving timescales and then missing them by big margins. It chips away at their credibility when they’re wrong and there’s very little ‘win’ in it for them to be right.

I want more info and I want to know what’s going on in the heads of all the team members, but if I was in their position and I’d been through what they’ve been through I’d be staying shrewd and silent in the name of the bottom line - bringing SAFEnet into existence.

Their best play is the same as it has been for a long time now imo; avoid the distractions and risks so they can get on with building SAFE and saving the digital world.

David obviously sympathises with our position, he made a real effort to give some broad dates (a decision that could bite him in the arse in 12 weeks when it’s quoted back to him lol ;)). I think he’s been as revealing as he can in letting us know his broad expectations for the near future (thanks again for that David), that’s as much as we could realistically ask given the circumstances here. He carries a lot of weight on his shoulders and he didn’t need to saddle himself with the additional expectations by suggesting we’d be iterating fast through the Alphas in the second half of this year. As a poker player I see a man making a bad play because of emotion (sense of responsibility/guilt and sympathy). David’s humanity is one of the reasons I have faith in him though. I know he’s trying to do what’s best and to make a difference. Really, the bottom line is getting SAFE out there, not knowing in advance when it will happen. I could imagine regular updates on date expectations could hinder that goal if not handled very delicately. Constant missed deadlines looks bad to the uninitiated in software development and innovation. Having to defend themselves and getting into protracted explanations about the roadmap dates is just more distraction from the only thing that matters.

Meh, I want to know their real-time expectations as badly as the next person, but I agree with David’s policy to be cautious and avoid exposure to unnecessary issues and risks. Same with NVO and any other non-essential, peripheral stuff. if it isn’t going to get SAFEnet launched any faster and it might swallow a lot of time or create issues then steer clear and keep eyes on the prize imo.


That was done some time ago. Everyone was hanging off a Tuesday update and they included the “soon” and “hopefullys” and “maybe” and it was a disaster for David and the community.

No timescales, no “soon”, no “maybe next week”, no more promises = no friction.


I think the people asking for timescales haven’t been around long enough to understand why they are a problem. I was in this position a year ago hoping to hear something from the team about time estimates. Progress has shown to be unpredictable. If something is unpredictable then you are likely wasting time attempting to predict it and probably giving out misleading information. No one wants the team wasting time or giving out misleading information.

Alpha 1 was late by about six months from its original estimate. Alpha 2 is about 9 months late from its original estimate. Many people have explained why timeframes with engineering can be difficult. The team should not have the burden of trying to get it out on time or to deal with the disappointment of investors/fans who feel let down by missed projections.


It’s not a lack of comprehension or understanding in my case. I just think it’s the right thing to do.

1 Like

Maybe some kind of percentage bar filling up

i didnt trust the time, but i knew when it was almost over


I can’t speak for everyone, and I hate to sound like a complete ignoramous, but I think from my perspective more education is necessary. Also the roadmap and other such resources need to be more clearly accessable from the forum and website. I didn’t even know where that roadmap was until @neo linked to it. (Thanks man.) And half the time I’m not completely understanding the weekly updates. Now if I’m not understanding them I’m betting there’s a bunch of people who are just silently lurking in the wings who are also not understanding them either. If an update doesn’t make sense the first time how do you link it to progress made in the next update, that may or may not make sense. And if THAT update doesn’t make sense how do you THEN determine how much progress is made over time? Over the process of several months if this level of confusion continues is it any surprise anxiety might crop up because no one really understands what’s going on?

These may sound like stupid questions but:

What precisely is routing, how does it work, what is it’s status now and how does it fit into the project? All I really understand is it has something to do with getting nodes to talk to one another and send data from point a to b along the network securely.

The APIs look awesome but seem written for someone already familiar with code. Who do I go to for assistance in understanding them or finding coding tutorials that will help bridge the coding gap?

ELI5 What is node aging?

Maybe I’m just particularly slow when it comes to the SAFE network and yes it’s embarrassing to admit all this but these are the kinds of questions that go through my head realistically when reading the updates and trying to keep up. So to get back to the anxiety issue and road maps we need more clear lay man level education. Also keep in mind there are new people popping onto the forums on a regular basis. So having a tutor of some kind that could take people by the hand and explain the updates and field other questions would be useful both for those who didn’t understand the first time and those who are new to the project.

SAFE is intended to be easy enough for your grandparents to use correct? Well if THAT is the goal we’ve got a long way to go because I’m barely keeping up and I teach old people how to use computers. Trust me that’s harder than it sounds.

1 Like

Lol I just thought of a Maidsafe health bar. +HP for dev progress. -HP for bugs and glitches needing to be fixed. Every testnet is a level up!


Wow. It would be amazing like that. Very good idea!

I think we should work on a glossary, with the main concepts explained in layman’s word:
datachain, data republish, node aging…


That’s not possible because you would need to know what exactly has to be done to finish the project (in your example, which files do we have to copy). They are continiously figuring that out, like currently with the discussion about different data chain options. Of course there is a rough plan but they just don’t know yet what exactly is ahead. Contrary to other projects, this is normal because of the genuine nature of the project.

I think the communication is just fine and as accurate as possible. However, I have two concrete suggestions / wishes for the dev / release process:
1.) Always make sure that the master branch is compileable (wasn’t always the case in the past).
2.) Make it easier to setup own / local testnets which can be used for development. The mock releases are not really sufficient / very useful in their current state for development in my experience (too buggy and can’t emulate a real testnet sufficiently). This would also reduce the stress about releasing self hosted testnets and remove the need for optimizing each release against various attack vectors.

In a perfect world I would wish for being able to just run 8+ vaults on a machine and being able to tell the browser to connect to this local network. This mould maybe even remove the need for mock versions at all? I don’t know though if this would be even possible.

1 Like

Yes, Dirvine I totally accepted your explanation on it. Every project talk about schedule, timescale, time frames etc. All the time setting as a target no matter how good or bad results out due to timeout. Always produce some defeat issues.
That because some developer looking for fast way delivery and make profit. They don’t care the end users benefit.
I always believe a good product can work with best condition.
Is not sold out and call back for defeat maintenance service.


I just encountered a video concerning the planning of ‘Star Citizen’.
This is a crowd sourced ($150 million now) space simulator game.
Probably mostly other kind of planning challenges than Maidsafe, but it could be inspiring nevertheless.

Not that I’m going to play that game, but I find the development process interesting.

Ps: the gamers are not happy now with the difficult to get and/or expensive video cards,
because of high demand by miners.
Maybe they can buy them cheaply from the miners when Safecoin becomes a success :grin:


I fully agree with Luke that a timescale would make followers and investors very happy, and it is a good thing to keep investors happy!

Also keeping a positive mental attitude will help for the success of this project: I read several pessimistic comments of the type “if we give deadlines we are not going to satisfy them”, but you could write: “here is the timescale and yes we are going to deliver on time”.

For those who have read Steve Jobs’ biography you may remember that he used to give very aggressive deadlines which did put a lot of pressure on the devs. But in the end people who worked with him appreciated and admired him, and it led Apple to a great success (although M. Jobs is gone :confused:).

Finally let me try to give an estimated timescale:
If I read correctly the roadmap Alpha 1 was released in Aug 12th 2016 and David Irvine says Alpha 2 is very close which could mean August 2017, so one year per Alpha.
Alpha 3 would then come in August 2018 and Alpha 4 in August 2019. M. Irvine also says that Alpha 4 will provide good visibility so we could assume that Alpha 5 is going to be the Beta in the roadmap, so Beta in August 2020. From there Release candidate could be in August 2021 if we assume the same duration as Alphas and the Release in August 2022, so a little over 5 years from now. This is of course if there are not multiple Betas or Release Candidates.
However if we consider Piluso’s and Neo’s comments we should multiply this estimate by 10 so this would bring the Release to August 2067.

I think that this estimate should calm impatient investors and not put to much pressure on the developers


Dam it, I’m away that whole month.