MaidSafe Dev Update :safe: 8th December 2015

Yes the tone here has always been understanding and calm, but we have been receiving worrysome updates for some time now and I think we all just want to see something real. Rust-5 was ages ago and it’s deliverables have never been seen.

When I really think about what might be going on, I think perhaps there may be internal problems possibly? This is a huge undertaking and a very multifaceted, complex project, so it would be completely understandable if there is a substantial internal problem with development (beyond what has been said already in the updates, etc).

Just please tell us about it! We’re all in this together, and we all want to change the world for the benefit of everybody together

4 Likes

As a programer who has done multi year projects. This news is expected. At times it can seem like whack-a-mole. They are in multi-week bug fixing and one thing about bugs is that they like hiding each other. You fix one bug only to find there was another you could not see until the 1st one was fixed. And so on.

The problem we have as on-lookers is that the dev team had done an amazing job for Rust-1 through Rust-3 and we expected the same to continue for each sprint. But when Rust-4 was nearing completion the bugs that had been creeping in reared their ugly heads because when you bring the modules together they each shine the UV light on the other modules and those nasty bugs become obvious and wreak their filthy ways on the system.

TL;DR

To expect clear sailing through each RUST cycle is unreasonable and bugs have a way of taking an unknown time to be fixed, especially with modules that do things no one has done before. It is unpleasant for all but is expected and the updates are actually encouraging, because some programmers just fudge quick&nasty fixes so they can appear to be progressing fast. Those quick&nasty fixes often cause problems later on and actually take longer to fix in the end.

Without some other information the progress does not support nor deny that thought. But I would think without other evidence there is no reason to think this.

1 Like

Lets be real. Routing is one of THE most difficult aspects of SAFE and the teams’ inexperience with a very new programming language had then (during the time of fault) caused some critical oversights. Who could of guessed.:confused: It’s cool though cuz now every dev member has become more intimate with each module as a result. I’m glad sh!t happened the way it did (almost Dirvine in sequence):yum:. Now we have informational and experiential decentralization in regards to SAFE among the developers as well. I’m very excited!:grinning: Yes, things all around could have been better but keep in mind the imperfection of humans and the scope of the task. These are in many ways the results of the supermen of tomorrow (to the rest of society) attempting to juggle every day life and catalyze worldwide communicative liberation. Please, cut them some slack. The result I believe, will permeate all of society. If not, it will have laid the groundwork within a fairly short time-frame. Everything I said can be argued, but lets just chill and try our best to use the current available data to make our multifaceted estimates. Did I ever tell I you that I skydive with incontinent cow monkey mycelial hosts. It’s the most optimal land ammonia dispersal and land reconstitution method I was told. My rational left brain rejected it at first, but my right distorted mind held welcoming wispy arms and a veracious appetite.:grin: Ya know wut I mean son!:wink:

1 Like

I think both sides here have absolutely valid points and it is a rather unfortunate situation for all involved parties.

Delivering a time line that can’t be held is not going to look good and will make it so much harder for the team to work effectively. Most likely it will result in less and less communication with the outside world to shield itself from further scrutiny. Good (project) management means that every participant should be shielded from scrutiny as much as possible. That’s what management is supposed to do, so everyone can do their job.

On the other hand, and this is where I come from and where we get into a grey area. Normally a project also has to deal with time lines. Normally, there is a client/buyer who pays in order to have a project delivered in a certain time line. This is always a fight, since the buyer wants to have it as cheap and quick as possible, whereas the project team wants to do a proper job and do it right, which means higher costs and longer time lines. The project management is there to find good compromises for both sides. A time line also ensures that there will be results, even if it is with a reduced feature set. But there will be results at one point, a goal that can and has to be achieved. If there is no time line, more and more features will be added and the project never finishes. One of the most prominent examples would be Duke Nukem Forever

With the introduction of crowd sourced projects (like kickstarter), there is no accountability. If the project fails to deliver (for whatever reason) there will be no repercussions. In addition, there is also no obligation for the project to deliver anything. This is the big difference. Investors have no entitlement to anything (they can’t sue for example when nothing is delivered and the devs just take the money and start living in Brasil), but they still have a little bit of power. If enough people invested in the project (not just monetarily, but also morally) are getting upset, the influence of these people will eventually kill the project. Once the reputation is ruined, it is very hard for a project to recover from that and gain traction again.

With that being said. I’m still a firm believer and supporter of this project. But I’m also very sceptical in general and from what I’ve seen outside our little bubble here, most people are. Because there is, apart from the local safesite, nothing to show the potential of this project, the only basis the community has right now, is your word. I personally still take your word for it, but that might not be the case for everyone and it most likely won’t get better with time.

While I can have a look a git and JIRA, it doesn’t do me any good. I can see that there is constant progress, but I can not say whether the project will work eventually. You could be programming the next version of the lunar module for all I know :wink:

So, if you’re saying, we can’t or won’t be finished with the dev bundle 1 (roadmap) in the next x months/years, the only conclusion I can reach is that you’re not sure when this will work and this is not a good sign. I like the weekly updates and the general chattiness with the community, but we still don’t know where the project is in terms of milestones. Even if there are major problems that need to be solved in order to release a first version, you should say so. Lay out the issues that are apparent and how you’ll be trying to solve it. Since we’re apparently not talking about a couple of weeks here, I think it’s better to get expectations on par with reality.

I hope you don’t see this as unwarranted, but I think constructive criticism is a good thing.

All the best

hillbicks

PS: http://julian101.com/wp-content/uploads/2011/02/image.png

8 Likes

Yes, all true but then again, if that is the answer (that there is no answer), why are realists on this forum called pessimists?

Is it 2018? Mid 2016? Some sort of commitment to schedules must exist.
It is complex, but it is not rocket science so someone should be able to paraphrase Kennedy and say “We shall put data on shared space and retrieve it SAFEly by 2018”.
If 2017 is mentioned, one is accused of pessimism and FUD. If May 2016 is mentioned, one is cautioned that promises cannot be made.

Obviously there is some hard limit, a date by which the project will, if unfinished, hit the Ethereum Wall (in terms of funding). In my mind a commitment should exist to deliver 3 months before that date so that the project can enter the crisis mode (in the positive sense) before it hits the wall and deliver something usable before those MSC coins have to be sold to pay bills. If the MSC day is (say) August 1, 2016, then a commitment to deliver by May 1, 2016 should be made.

(My status is not “investor”; currently I don’t own MAID, I’m just eager to use the network so interpret this comment as you wish)

8 Likes

That’s not what Nick is saying IMO:

And Rust 5 deliverables means a global network where everyone can publish their own website.
I agree everything is taking long and we all want to go live with the network today. But remember a few things:

  • The architecture of SAFE is changed for a very big part. Remember February this year??? I’ll quote David from his blog:

Another quick post, I hope this makes sense, it is perhaps the most exiting aspect of MaidSafe I have found so far and the consequences of this are far reaching indeed. It will not be obvious, but please ask questions on maidsafe.org and I will try and explain more of why this is very important, not only to launch with but to move forward and also model system components very quickly.

Just take a look at that post again and understand what a big difference this was to the project. I’m actually surprised we all had installers and the possibility to run a local network in September. That was a very fast change in architecture!

  • And the second thing to notice here, it was written in a completely different language! So in under a year both the architecture and the language were changed. Want a roadmap now we can look back? Here it is:

It was done in under a year!

And I know these dev’s don’t have easy workweeks making 40 hours or so. I know they’re working much longer than that. This is not like building a house from scratch where you have it all planned out. This is more like designing an Ant from scratch where you have to write the DNA as well. Quite a hard job. Just take a look at the work-flow diagrams about Bootstrapping and Node Discovery. This is a completely new way of P2P and networking. It’s never done before.

So I’ll just relax, follow the process and remind myself that I already had the network running here locally. With the new architecture and written in Rust. The Ants are coming folks :+1: I wish the dev’s all the best and I know they’ll deliver.

2 Likes

Is that a bug or feature?
Was the previous design unworkable?

Same questions as above.

Yeah, it’s great that these (hopefully) improvements have been made, but it until we know their effect we can only conclude they serve to delay the project. Maybe the bets will pay and maybe it will turn out to be a great decision, but at this very moment it’s a bet that hasn’t been decided. I think no one questioned these changes (that is, they received community support), but you cannot use that to justify the delays.
The changes were supposed to make the project be finished sooner and be better, and now you’re using them to explain an outcome that’s almost the opposite (delays and new issues).

2 Likes

Yesterday this thread contained a post urging people to sell safecoin before the value drops to zero.

The fact that this message got censored is the most alarming development to date, as censoring is usually used as a last-ditch effort to contain the truth.

2 Likes

Where’s that info? I’ll like to know your source.

What I got from it is that it makes adding new features more easy to implement. And going from over 500K lines of code to under 20K with the same functions is a pro without a doubt. Especially when new devs out of the community want to write code as well.

You are really asking if it’s a bug that they moved to a new architecture?? And how can a new architecture be a “feature”? The software is meant to run a very big number of features, so calling a change in architecture just a single feature is a very weird way of looking at things IMO.

I never said that the last issues are due to a move to a new design and/or a new architecture. That’s putting words in my mouth that I’ve never said. I think the opposite is true. It would’ve been way harder to fix any bug in the old architecture and language. There was way more complexity in C++ and the old architecture.

That’s just an assumption. You don’t know if things were slower or faster progressing in C++/old architecture or not. But again, I think it speeded the thing up. Just look at this presentation by @ioptio. It explains in a great way why the decision was made.

2 Likes

That’s correct. We not only removed the post but we actually banned the user. Not because he/she was posting a speculation about price. That’s free for everyone to do on this forum in the topics about Safecoin. This person was a troll. Made 3 different accounts here and the only thing he/she did was posting FUD about how the project was going to the ground and Maidsafecoin was about to be useless. Again, every one is free to say that. But not in topics all over the place and without any further interaction in the communication here as well. That’s just opinion spamming, trolling and not improving any discussion. It was actually the only thing that person did here on the forum. He/she didn’t respond to any replies, didn’t take part in any discussion.

14 Likes

Not unworkable but inefficient. You don’t want to learn how to ride a tricycle if the desired vehicle is a Porsche. It would be misleading.

That’s personal lack of knowledge. I mean, they can’t satisfy everyone. Real world data is highly volatile. Their decisions are those of informed engineers. Do you doubt this? Delays can be individually justified by anything that is decided by the indie. What you seem to mean, is that it does not conform to your sense of acceptability. If not why argue? Early release means greater risk.[quote=“janitor, post:67, topic:6289”]
The changes were supposed to make the project be finished sooner and be better, and now you’re using them to explain an outcome that’s almost the opposite (delays and new issues).
[/quote]
We’re peering into a deep preparational plane. If your expecting explanations at this stage, some real world programming experience would help you rationalize your expectations.

1 Like

There are no problems beyond what has already been communicated in the updates, the team are working really well together and we have continued to strengthen the team by taking on an ex Googler in the past week. The Routing library has just set us back a bit and as you will see shortly that has continued to be addressed. We continue to tell you everyone about it on a weekly basis and with the Rust 5 deliverables being close you should not have anything to worry about.

It seems that not giving timescales is creating the belief that we are further away than we were before, that is not the case, while we have taken a detour with Routing we are back on track, with some changes being required in Vaults to accommodate the changes in Routing. All that I am saying is let us deliver Rust 5, which will remove any doubt about the network functioning, and we will publish a more detailed roadmap from which all remaining work is clearly laid out and from which it will be possible to derive timescales.

14 Likes

The actual facts here are that routing was thought out well but not coded well at all. It was messy with unclear issues and ignored errors etc. This is due to us not having enough people there as opposed to anyone in particular. It was too much for the people in routing who typically tried to work too long hours and just get it working. that was a failure and should have been addressed sooner. Even with daily catchups it was not caught.

A good lesson, if anyone is unclear in catchups we will dive into it much quicker in future.

So now we have 5 folk in constant hangout and working all day and night to fix it. This means as usual almost 50% of code is deleted (a sign of direction loss is too much code).

We will get it cleared up, we hoped Friday would have done most of it, so today and tomorrow we are in last leg. After this we will quickly confirm vaults and client API are using routing correctly ( a small task).

So it’s not a simple timeline, just the bottom fell out of us managing the routing library and on hearing unclear updates, hoping everything was OK, it was not. So we failed to pick that up but will not fail to fix it. It’s not something we wish to have as by now I wanted messaging and safecoin included in the installers we all use from home.

Routing is ultra important and even after this fix we want to clean it up more. However, to get to MVP (minimum viable product) we are pushing the fixes through with clear documentation to allow a smooth future for this lib.

So sorry folks we made a mistake and are paying the price personally and as a community, but your devs are on it and on it hard as possible.

Thanks everyone for your patience and lets get this all in place during the next few weeks, I hope. The devs are really tirelessly attacking the issue we allowed to happen and a big thanks to @viv here as he dived into routing, worked out the detail and is managing the fix by documenting flow of logic and messages with great clarity. A big job handled very positively and with a ton of energy with the rest of the guys really just focussed 100% on the fix and not on the forum for now.

So thanks also to @nicklambert for being our conduit to you in the meantime. He cannot and will not give timescales for rust-5 completion as he cannot, we are not speaking to him all that much as we are in hangout. It’s not months of work to fix this, it’s weeks and most of the weeks are behind us now.
When routing is solid everything else falls into place (language of the network) so we will be in good shape soon.

32 Likes

The design of the network has evolved as it has been implemented, but from my position the core of the design has very much remained intact. [quote=“janitor, post:67, topic:6289”]
Yeah, it’s great that these (hopefully) improvements have been made, but it until we know their effect we can only conclude they serve to delay the project. Maybe the bets will pay and maybe it will turn out to be a great decision, but at this very moment it’s a bet that hasn’t been decided.
[/quote]

From my perspective, moving to Rust has been a success. It has enabled us to apply accountability to each of the part of the team, reduced code volume and complexity and enabled much improved, although still not perfect, project management. You are right that it has still not resulted in a useable network, the main aim of the move, but we are very close and nothing will give us greater pleasure than to give you installers and you can judge for yourself whether the move was a good one.

14 Likes

Thanks for the clear explanations. I suspect many are starting to ache with the delays and that hurts everyone involved. However it’s not like we’ve supported the production of a ‘pie’ (as in easy as pie). It’s more like we’re supporting the development of a machine that makes machines that makes pies…An anonymous internet is the dream and from the start, nobody said it would be easy.

7 Likes

Sorry for adding my worries to the pot there, and thank you very much for the replies!

I care about this project more than anything and want it to succeed, and I just got worried. But I definitely believe in you guys! I’ve been here for maybe 2 years now? 2014? and have never been so inspired and captivated by any project in my life. Sorry for my moment of weakness…

Random aside: Here’s hoping for a decentralised direct / liquid democracy replacement before Donald Trump takes charge of our armies and foreign policy-making…:stuck_out_tongue:

7 Likes

I’ve got enough user experience in cryptocurrencies, storage and startups to be able to make reasonable comments and form reasonable expectations, thank you very much.
Besides my point is that the hard deadline is funding. Unless the strategy is to hope that Bitcoin or MSC will appreciate or that new investors or grants will pour in, there should be a target release date (maybe 2, as I said, soft and hard). That is unrelated to programming. It’s a constraint that should receive due consideration (and it likely does, but we just don’t know about it which is what other commenters on this topic observed before me).

I hope the changes are going to shorten dev time and save resources as explained both before and now.

Not true. That’s all. The rest I expect you to discover or already understand. These games are getting lackluster.:expressionless:

David, Thank You for your plain an direct explanation and the devotion of you and your team to bringing to the world
such a first rate network and the hope of truly free expression of ideas and communication for all.

5 Likes

For all of you calling for timescale estimates in order to give you confidence and alleviate your discomfort, take note of what David says above. The problem we hit here is only made more likely by the added pressure Devs feel from such. They were trying to meet unrealistic expectations of time!

I’ve said this before, from my decades of experience of development in contract technology design & development (from blue sky research, one off equipment, prototypes of products from missiles to a handheld teletext receiver, and the last ten years in software product development) I have not seen such a challenging project being managed as well as this, and I have full confidence in David and this team.

You don’t help the project, especially one that is rocket science, by getting someone to make estimates, or guesses FHS, of timescales and make them public when they are going to be so speculative.

I learned early in my own management of projects this kind: estimates are almost always wrong - which in a customer-contractor situation then leads to things behind cut and/or delayed, as the project gradually uncovers reality.

I learned that there was one, and only one, reliable way to estimate such developments: if you had done something similar enough before, and could base it on that. But this is new ground, and very high complexity, so it’s impossible to estimate.

Once the foundations are working, that will change and later goals might be easier to estimate, but all the foundation work is very different.

So you can do your part to help the project by trusting David, and listening to community members who have experience of this, and accepting that there is a big risk in this kind of development. It might take a long time, it might not even work. But you can reduce the chances of either by doing your bit to support the team, and trust they are the right team, and doing their best.

There is plenty of evidence of that. Unprecedented in my experience, so please don’t speculate, and inform yourself rather than post things based on your fears or speculation.

I think it is disgraceful to accuse an individual of having ********d up based on speculation, and I hope @Tonda will withdraw that comment.

5 Likes