RE: An Objective look at Dlive's exit
Great discussion @fknmayhem and @meno, you have represented both sides of my thinking on the matter better than I could have put it so there goes the need for me to put that together in a post!
Fkn I'm kinda surprised you're the only one I've seen saying that this is just cut throat business led practices. I know the guy doesn't get much love around here (get ready to be triggered) but as George Soros said, the market is amoral. That is the reality of how people operate in business and crying about it is pointless.
I'm also baffled why people are not saying that DLive did actually contribute a lot to Steem. So it can all be boiled down to a broken promise that was never made: DLive is here for the long haul.
However @menos has convinced me that the level of ninja operations is counter to the spirit of Steem. That they didn't integrate more with the blockchain is a red flag. We definitely want to encourage any and every company to use Steem as a payments layer, but only those who integrate well in the full ecosystem should even be considered for Stinc delegation. Hands down.
I think people need to calm down and sit back to reflect on the assumptions they had which have been exposed as a result of the DLive exit. In what way did they not do what was required of them? Why did we think it was a requirement?
There are sharks out there and it's foolish to blame a shark for chowing down. What we need to be skeptical, rigorous and honest. DLive made no promises that have been broken - to the best of my knowledge. If it turns out there were promises broken in private conversation with @ned and co that's a problem that we don't know them.
One thing I have considered in recent hours is whether the license should require apps to be opensourced. AFAIK DLive never opensourced.
Yet, AFAIK that’s not compliant with the MIT license of Steem. A license I vastly prefer over the much more restrictive nature of its obvious copyleft GNU-GPL alternative which would de facto require that for almost all. Yet even an opaque app could function within the GNU-GPL as happens for example with Akismet spam filtering for WordPress. The plugin is open sourced as required by WP’s GPL3.0 license yet not the matrix. So we wouldn’t be much further either, we would merely have a more restrictive license.
Open sourcing, or rather the lack thereof, is a red flag to me though.
That's a good suggestion, and requiring it by license inheritance a neat trick.
Except, of course, that by enforcing it you would be deliberately and aggressively limiting access to creators who want to create digital applications which might be terribly successful, and thereby increase the value (both physical and personal) of activity on the steem blockchain.
Not to mention the impossibility of enforcing that requirement. Given the general lack of governance in the context of the blockchain as is, trying to suggest policy which requires governance which has no mechanism of enforcement is like wishing in one hand and spitting in the other. I suppose at least you have some spit.
What we really need are more reasonable applications that provide actual value to someone's personal experience which just happen to use the steem blockchain.
The problem is that for most of the developers around here, the blockchain comes first – and the idea that the digital application should solve some problem will provide some value to user comes much further down the list.
Fix that first, and the rest looks after itself.
Aside from that, all of which I wholeheartedly agree with, I truly don’t think that it would be compliant with the MIT license.
And if by inheritance then only the connection layer could be required. Not anything which happens outside of the BC.
Personally, I much more prefer the more open nature of the MIT license over the restrictions of GNU-GPL3.0. Plus the MIT license is compatible with more licenses than the copyleft licenses are.
It is a significant challenge to make things compatible with open source licenses as they are written these days, at least if you ever want to make significant money off of it. This is a bit of a carryover from a lot of the social assumptions of the people who actually write these licenses and have written these licenses, who believe that making money is morally tainted in the first place.
My position is that I think that trying to dictate whether digital applications which touch the blockchain are open source or close source is inevitably doomed to fail, upfront, because it's simply unenforceable and flies right in the face of the design of the technology.
Unless we want to demand that all the voting bots on the steem blockchain prove that there open source and provide that source to us, which would then require that we be able to detect them immediately upon touching the blockchain, keep them from being able to interact until they were checked off, and then allowed back on.
We can't even detect bots consistently.
So – since it's impossible to actually make this policy happen, discussing it is at best a waste of time.
Interestingly enough we shouldn’t have these $hitstorms in a teaglass, which will be forgotten come Monday anyway, because this blockchain is ruled by a Code is Law approach.
No code was violated AFAIK.
As for “the spirit of...”, I thought that was something the rather arbitrarily nature of code is Law would fix.
The MIT license is IMHO a very nice license and ruled by less “pitchfork spirit” than say the GPL scene. None of which are against commercialism yet one first wants to make sure that the spirit is on sharing where the other states to first respect the open nature of the license and seems less controlled by rabid dogs culture.
This is absolutely true, and that the position to which I adhere as well. But if there is anything that we can count on when anything (anything) happens on the steem blockchain, it's that whiny bitches will climb out of the woodwork. Some of them will be whales. Some of them will be the proxies of whales. And some of them will just be entitled kids who think that they deserve the magic money numbers in their pocket to go up all the time, and they don't care why it happens or how it doesn't happen.
For extra points, work out the Venn diagram of how these groups overlap.
I'm familiar with the licenses in question and if I were going to be releasing some software myself, the MIT license would be very tempting. Unless I intended to sell it, in which case I definitely wouldn't go with the MIT license.
Though it's a bit off the line of discussion, I always find it amusing how often libraries with viral licenses get used but those licenses don't get applied to various pieces of software. That should be someone's summer research project at some point, to go through github, looking at open source projects, looking at what libraries they use, and seeing if they actually follow the share-alike viral license requirements for the software developed using those libraries.
But I have a sick sense of humor.
Upvoted for the Venn diagram.
⭕️
You're correct. The context under discuss here is about improving Stinc's delegation policy.
Which is just not going to happen. They have a vested, very direct interest in getting as many digital applications using the steem blockchain as possible. To that end, they have an aggressive pressure not to care whether or not the project is open source or not but rather whether or not people will actually use it – which is entirely orthogonal
And if we're being cynical, often the closed source solutions end up being better developed. The developers end up having I'm much stronger vested interest in doing a good job because no one else can take their work and run.
That doesn't apply to all things, of course. Anything that depends on a level of trust of the user in order to get the product they desire is going to have a certain extra level of cachet if it's open source. Anything that makes claims about how things work is going to have an extra level of assurance if it's open source.
But streaming applications? That's not a big deal.
Steemit Inc. has made a lot less reasonable, less explainable delegation policy decisions than the one that went to DLive. And notably, even if DLive were an open source project, everything that is happened could easily have happened just the same way because that has nothing to do with whether they decide to take their work to another blockchain.
Policy that would make no difference makes no difference, no matter what.
I think they are significantly annoyed by the DLive exit for the motivation to make a few changes.
Do you have any suggestions for policy changes that might be effective?
the STINC delegation did not cost any time or money. Steem gained more investors because of dlive and the delegation. End of story.
I'm interested on how you came to that conclusion, since steem has lost so much valuation since @dlive showed up.
Could you show me a chart that shows STEEM increasing against satoshis and cross reference it with @dlive's contribution timeline wise?
I mean no offense when I ask, I'm simply putting this out there, because it seems that many investors don't understand that inflation is a "tax" on people who bought tokens with BTC.
But please, explain your point.
(edit)
I'm not blaming @dlive for the valuation drop. I'm simply stating how you say it brought more investors and how you draw that conclusion.
I would not have invested much in to steem if dlive had not existed. I know many people on the same boat.
If your argument is that the inflation created through dlive's curation outweighed that of investors they created, that is possible. To be fair we have been in a bear market for 8 months.
That could be anecdotal, and the conversation to be productive must be looked at in macro. But I don't dismiss you words, because this is your personal truth and as such is valid for you and your positions.
In order for this to make more sense, or at least for you and I to talk with the same information as a foundation. Look at the price of STEEM against BTC since the launch.
The inflation has always pushed STEEM down, it's a downtrend overall.
I completely agree with your entire comment, but this in particular strikes me as relevant going forward.
Thanks!