I like the rocket analogy. E.g. for instance the moon program.
A million requirements of a million moving parts. Each had to be simple, and each had problems, e.g. even when they thought the engines were working, they discovered instability. Early on, they ditched their first concept (direct) for the lander and orbital rendezvous, because, even though direct was much simpler, the requirements for delta V were beyond what could be built in a rocket. The actual lander and rovers had to be developed without knowing exactly which environment they would find themselves inā¦ they had no idea if the surface of the moon was more like rock or icing sugar. When the first one launched, they had tested all the various systems and thought that it would work, but everyone was crossing their fingers.
So it is here. A single goal, unworkable approaches discarded, many tested systems, but interactions unknown. I do believe the current approach will workā¦ and I suspect the next testnet will be a vast improvement over the last one, which was already a decent proof of concept.
I think in the past the delays have been caused by ultimately the foundational technology aspects not being fit. And of course bugs. But now I think it is all bugs.
The vision, optimism and predictions are always going to be different from reality. Notice how slowed down reality seems to become during all of the Thursday updates that focus on how many snags of bugs are occurring. This is why this time, refactoring is of utmost importance to eliminate the bug of the bugs, since all we have are bugs instead of a broken foundation. Correct me if Iām wrong but I donāt see any talk of needing another foundational puzzle piece to be different entirely, though I suppose there could still be new addition to the code to complement the current pieces especially moving forward around Maxwell and such.
If you take the time to read the project network roadmap on safenetwork.tech you would know that a stable Fleming network is the āprovenā foundation.
Glad to see you are still on here and actively advocating for the company approaches. As a dev too, normally I would agree the technique presented is a great approach.
But for this project specifically I would likely conserve on finances more so than usual at this stage and only focus on core network deliverables so that until its done, coin investors and the company get the max bang for the buck. Mainly because the project has had so many ground up revisions eventually one approach must be settled on and fully committed to for the initial network. Both the internet and those that invested in the company and the crypto coin, the long term holders deserve to see the project reach a full deliverable of the basic. So whatever gets that ground framework out the door, even if the company goes broke and cant promote it or build the UI etc. at least it will be open source and the torch could be passed onward, but lets hope a real reliable network comes to fruition and yall get time to write a good amount of client integrations too and act as the initial promotors until those in tech see its use cases and it grows organically over time.
Or more likely could be if the coin in fiat price takes off when network is live that will attract enough raw general public attention that if docs and use cases are easy to follow, then it will go used by folks and grow naturally.
Arguably, the Bamboo Garden fund could be considered for client side apps too. Maybe some of those apps can be handled externally by the wider community too.
Imo, it is the core than has maximal complexity and needs the Maidsafe teamās attention the most. There are lots of moving parts which benefit from a team experienced with working on them.
I canāt imagine the frustration of not putting out an MVP during the same general timeline that it often takes to create working vaccines. Iāve only been around for 5 years so it must be horrible. As pointed out above so many close calls in the past, now likely another bitcoin cycle away from keeping our fingers crossed.
If you believe that an MVP type product will be released in the next 6 months or so then Iām wrong. If not then Iām likely correct based on history
There appears to be a lot of optimism on the progress that has been made but from what Iāve read it also appears that there remains no internal timeline for projection. With that being said, as someone highlighted in another post, the track record of ābeing closeā and then pretty much abandoning course is what we have to go off of unfortunately. We also know that Fleming still is not complete and maxwell will have to be after that to launch with components including dbc and SNT. On top of that the UX has to be fully ready, how many more test nets and debugging ect. Itās not 6 months away.
That all leads into me considering a cycle from when the halving happens until the next halving occurs. Others judge it in other ways perhaps but that to me is easiest way. So Iām suggesting no release until mid March 2024, earliest, little more then 2 years away.
OK, thank you for your rationale on that. I am more optimistic and now am convinced that we are just tidying up for Fleming, there are no more detours, its just slog to get it complete. The research is done, its engineering now.
As for Maxwell, thatās another story. However I believe most of the research is complete there as well. A successful ālaunchā of Fleming will bring more eyes on the project and hopefully more resources to get Maxwell complete and an MVP in Q4 2022/Q1 2023.
I go through a mini cleansing every 6 months. Iāll either rise with the tide or go down wit my the ship, but im now 1 part optimism and 1 part reality as this has gone on much longer then I would have expected and im sure much longer then developers would have hoped for or expected.
