From the Wikipedia definition:
A project post-mortem is a process, usually performed at the conclusion of a project, to determine and analyze elements of the project that were successful or unsuccessful.
As HF 20 settles slowly into place, I decided to write a short piece about the current status of the ecosystem. There is a lot of confusion around the roles of the people involved, and most humans, unfortunately, are wired to react with frustration to any confusing situation, instead of careful analysis.
Who Runs The STEEM Blockchain?
My answer to this question is: witnesses. What is a witness? According to the white paper:
Conceptually, the consensus algorithm adopted by Steem is similar to the consensus algorithm adopted by companies throughout the world. People with a vested interest in the future value of Steem vote to select individuals responsible for including testimony in the public record. Voting is weighted proportional to each individual's vested interest.
So a witness is an individal responsible for including testimony in the public record.
Who Builds And Maintains The Software For The STEEM Blockchain?
The software powering the STEM blockchain is open source. So, theoretically, everybody can build and maintain the software for the STEEM blockchain (there are already some forks of the main repository, both public and private).
But, in reality, the software is built and maintained by Steem INC, a company which not only launched the initial product, but it's also highly invested in the ecosystem. Accounts owned by Steem INC, like the 
So, we have two main roles:
- builders of the software
- witnesses (enforcers of the software)
What Is Required For A STEEM Witness?
Here are just a few qualities (or characteristics, if you want) required for a witness to fulfill his role:
- 24/7 hardware availability
- moderate software knowledge (to build, install and maintain the nodes)
- political skills (to create and maintain alliances with relevant stakeholders - for securing his position from whales)
- communication and community building skills (to secure his position from dolphins, minnows and redfish)
Some witnesses have them all, while some of them have only a part of them and rely on association or delegation to fulfill the rest.
What Is Required For A STEEM Developer?
- strong C/C++ coding skills
- strong cryptography skills
- strong knowledge of distributed systems
- strong testing skills in distributed systems
- loyalty to the employer
In my opinion, all of these skills must be in top 1% of their respective category to ensure a consistent and high quality product. If any of these is lower than that, then we may get into trouble.
Is There Any Overlapping?
In an ideal world, the two categories will be completely separated, because any category will be sufficiently incentivized to maintain its role.
But then again, in reality, there is significant overlapping. Some of the developers are also witnesses and some witnesses contribute to the development from outside the company (open source model makes this easier).
This overlapping may be economically viable for some of the participants, but it creates significant liabilities. For instance, if a dev is also witness, he can strike the balance in favor of a new hardfork.
Something like this happened in HF 20: the software wasn't sufficiently tested, but, since in the first 20 witnesses there are a few devs, and since the rest of the witnesses blindly trusted the devs, the public version was released at a lower quality than required. So low that the blockchain first halted (an extremely serious event) and then was rendered unusable by a bug in the RC plugin which didn't let people actually interact with the blockchain.
Is The Role Overlapping The Only Problem?
Again, just in my humble opinion, I don't think so. Role overlapping increases the confusion and can lead to so called "black swan events", but it's not the only problem.
The other, most important part of the deal is "expectation".
What's expected from a witness? To just be responsible for including testimony in the public record?
What's expected from a builder? To just build, test and ship code?
What's expected from Steem INC? To keep paying for new accounts? To steer the development in the direction they consider relevant? To hire more devs?
And then, when some of these expectations are not met, what's happening? Are there any real life consequences for this?
All in all, STEEM is just a tokenized social media business, so, in the grand scheme of things, if everybody does their job well, and the product is good, the value of the token should rise. And if things aren't going well, the value of the token should go down.
But it's this the only incentive that we have? It's this the only way to measure the quality of our efforts and involvement?
I don't think so.
I think we need better processes, and these processes should be built on readjustment of both roles and expectations.
So, Which Way To Go From Here?
HF 20 was a failure, one that it is slowly solved by small, incremental patches. But a failure.
The main cause of it was, in my opinion, the lack of a proper testnet, one that could be accessed and investigated by witnesses, in their capacity of the first beneficiaries of any hardfork. Two years after launch, to run a blockchain based social media platform without a testnet was just inconceivable, a time bomb. And, with HF 20, time ran out and the bomb exploded in everybody's face.
Let's stop for a second and think about that. It's not that if something goes wrong only devs are to blame, or only Steem INC, or only witnesses. We all suffer. Just like when things are good, we're all getting the benefits.
We're all in this together, wether we like it or not. So we have to solve this shit together.
Here are my proposals for the next stage of this (let's face it, very interesting so far) experiment:
Consensus changes (enforced by code)
-- increase the amount of core witnesses from 20 to 40 and reassign the rewards accordingly (if now a top 20 witness gets around 200 STEEM / day, decrease it to 100 STEEM / day) - reason: the top 20 is becoming inertial and easy to control, also the lower the number of people who control the direction, the bigger the attack surface by bribe, negligence, etc. A bigger community of core witnesses will be more balanced. Also, from a technical point of view, that will give 2 minutes to restart your node if you have troubles, instead of 1.Non-consensus changes (non-enforceable by code)
-- dedicated testnets for various versions of the blockchain. reason: we need to test stuff before we release it. In case you didn't get it from the first time: we need to test stuff before we release it. And yet again, for those with a short memory: we need to test stuff before we release it.
-- transparent communication places for witnesses and devs (slack, chat, whatever) enforced by turn based moderators to avoid deviations and FUD. reason: communication places now are more or less casual and it's easy to stir up frustration and unproductive talking. The need for communication between devs and witnesses is huge.
-- pre-approved features for each hardfork, use a tool for voting all the features that we want to go in the next hardfork (as opposed to just write a post wether or not you agree with it). reason: too many features are increasing exponentially the risk for bugs, not enough features may jeopardize progress
Thoughts?
I'm a serial entrepreneur, blogger and ultrarunner. You can find me mainly on my blog at Dragos Roua where I write about productivity, business, relationships and running. Here on Steemit you may stay updated by following me 
Wanna know when you're getting paid?
|
I know the feeling. That's why I created steem.supply, an easy to use and accurate tool for calculating your Steemit rewards |