RE: Improving Steem's Hard Fork Process: Where's The Documentation? Decentralisation in Theory Only?
So – here's the thing.
You cannot have "distributed anarchic development" and "organized and structured development" at the same time. It's literally impossible. It takes a strong managerial degree of oversight and really significant resources dumped into rewarding the people that do the least pleasant grunt job in software development (documentation) to make sure it happens. That's why projects in banking, oil and gas, and the other panoply of five-nines/high-availability/high responsibility engineering cost out the ass. Someone has to get paid to do work that nobody wants to do, and someone has to get paid to check all of that work that nobody wants to do – because nobody wants to do it.
Moreover, those things are expensive and time-consuming but organizations with strong central planning architectures execute on them because the consequences of their failures are even more expensive and their successes are ridiculously valuable.
None of these things are true with systems with anarchic, distributed development. If they become true, a central managing body steps in who has the money to invest in the stuff that nobody wants to do in order to reap the benefits of a lucrative success. And that is literally the best you can hope for.
If you're designing a system that requires delicate, highly documented, deeply reviewed software in order to function in a way that it's consistent enough to be trusted.
And that's really the point and the problem.
If we look at functional distributed network/communications systems, they are designed to be inherently resistant to the kind of failures that we see in the majority of blockchain designs including steem. They are designed to be robust in the face of nodes which are explicitly out of revision. Most of them are designed around a protocol specification with the intent that there be no "witnesses/miners," but instead individual participants are responsible for their part. And in the main, they can get away with that kind of anarchic, truly decentralized system because it's a system that's intended to be as minimal as possible in order to provide an attack surface for as few problems as possible.
That is not the case for the design of the steem blockchain. Quite the opposite.
So we have to know up front that the steem blockchain is not a good candidate for what we would think of as proper five-nines software design or software management. We have to know up front that everyone outside of Steem Inc. is effectively a volunteer, and volunteers hate to do boring work – especially volunteer engineers. We have to know up front that Steem Inc. is not interested in doing five-nines software development because they have had vast amounts of opportunity over the last two years to engage in it, and have actively shied away from it.
So what's the solution?
Well, we can continue to depend on the witnesses to theoretically advocate for good development methodologies and hope that they care about such things at some level, at some point enough that they will sink their own money into some sort of management organization – but I wouldn't hold my breath. And beyond that, not a damn thing.
Which is also about what we can expect in terms of change when it comes to how the system is managed.
That's really the bottom line.
I'm not sure about that. Structured development really just involves a set of stages that include deliverables that perform functions within the development process. Some deliverables are documents and some are code. The introduction of documentation into the process does not require 'rulers' in the sense of being something that makes anarchy impossible and it isn't prevented by the process being distributed geographically since we have the ability to share documents in realtime (plus communicated with audio/video.. We aren't yet able to hold hands remotely, but that isn't really a necessity here anyway).
All that is needed is for Steemit inc. to pay someone to do technical authoring and to work with the designers/coders. Usually it is ideal for such a person to also be experienced in system architecture and coding, but it isn't 100% essential. Steemit inc. already has a development team and a manager. The team works together, according to a plan and makes a product. It is true that to keep the process coherent requires a cohesion and the presence of a strong guiding force - but that does not need to be based in a top-down control model, it can actually just be a shared vision of the need for things to be a certain way. I have worked on a large open source social software project for a few years and while they didn't publish full documentation of the kind I described in my post - they do publish full commenting and do stick to rigorous requirements for those to be created for all new code. If code doesn't include comments that meet standards, it doesn't pass testing and get into the builds.
Having a true collaborative culture requires the understanding of the benefit to do so, but perhaps the difference is that in the other project I referred to, there was no direct financial element involved giving people a sense of 'losing out' if more people get involved.
In some cases that might be true, but the kind of documentation I am describing is actually a standard part of a structured design process, it is not 'an annoying addition' but rather is actually a part that forms the foundation of the rest of the work. In such situations there are many people who greatly enjoy producing such documents. This is similar to architects designing a house on paper - it might be time consuming work, but many love it all the same. Does a builder love making such documents? Probably not and probably has no training at doing it. Does a pure coder love making such documents? Again, many seem not to really know fully how to do it and so are not attracted to it.
Part of the issue with Steem, that many people are ignoring, is that the success of the project is not just about technicalities - it is about PUBLIC IMAGE. The value of tokens largely revolves around perception, hype and prediction (as well as actual value and utility based on tangible things). While a few days of difficulty in using the system might annoy people who use the system, in itself it doesn't equate to the kind of damage that might be caused by a system failing that is designed to measure earth movements to protect oil drilling systems, for example. However, not only does the image of the system get hugely hurt by such downtime (lowering the value of the system in some people's eyes) - it also infers that the use of Steem as an actual method of exchange, rather than just a social blogging platform, is not really as great an idea as it might otherwise seem. No-one is going to die through not blogging for a few days, but we lived in a world where Steem was a primary currency used for daily exchanges and we suddenly couldn't use it, then real problems could arise.
Anarchic dynamics have the potential to result in greater productivity, balance and effectiveness - imo - provided that those involved understand how to achieve that without relying on being controlled by others. In other words, true self empowerment and self determination - when used to create effective teams that work together through agreement to use best practice - can produce teams that are capable of employing such structured approaches simply because the approaches work well and those involved value them.
I appreciate that maybe the majority of those involved simply have no desire to work this way, though they have not said so and I for one don't really know the truth of that. I am just putting forward a reality that I think deserves to be considered.