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.
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.
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.
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.
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.
Do you have any suggestions for policy changes that might be effective?
This assumes that I think there's a problem with this activity, and that's an assumption without facts in evidence. In fact, just the opposite – I think that DLive making the choice to pursue what they think is going to improve the situation for them is both healthy and necessary for the growth of the steem blockchain, if that's something you care about.
They have a very data-intensive backend that is integral to the service they provide, and there are other services which would be equally data-focused, and we need multiple examples in order to determine if the steem blockchain is even a reasonable architecture for such a thing to pay for itself.
Bandwidth is not free. Hardware is not free. Time is not free.
The more competitors in a space, the better the we can determine whether or not that space is actually exploitable.
It may simply be true that DTube and DLive didn't have enough baseline differentiation to make a go of it in the environment provided by the steem blockchain. As an ecology, there simply may not be enough material that people want to engage with to keep multiple services afloat. It may be so that there aren't sufficient resources in play to keep even one service afloat, and now that DTube has another competitor that is seeing a tiny bit a traction (Vimm.TV), we may discover that another service finds it necessary to either shut down or migrate to another social media-esque blockchain as its notification backend. Which one it is remains to be seen.
But taking a broader view, all investment by a company in another company which is producing a derivative product carries with it an element of risk: the risk that said product will not be able to be sufficiently profitable to continue the project as it was. Steemit Inc., for all of its other failings, at least recognizes that and I would be somewhat surprised if they went on record in a significant way denigrating DLive for making a business decision that was profitable for Steemit Inc. for a solid year. That would be terrible business and it would create doubt in the minds of potential future application developers as to whether they want to invest their time and effort in a blockchain whose management organization would burn bridges after them.
Keep in mind, we are simply talking about delegation of SP, not any investment rounds, real money, any of that. Those sorts of things generally get tagged with contractual obligations in violating a contractual obligation is a legal matter. But we have systems for taking care of that.
As I understand it, the delegation of SP to DLive didn't come with any strings, at least any that anyone knows about outside of either organization. Likewise, neither did the removal of the delegation – because delegation is not investment in a reasonable sense. Delegation is just providing the ability for the person so delegated to work the levers of voting on the blockchain just like anybody else, only with bigger levers scaled to their SP. Effectively, Steemit Inc. didn't give any money to DLive by delegating SP, they just gave DLive the power to direct more money – and if you look at their reports on a weekly basis, which they produced and were very forthcoming with, the vast bulk of it was sunk right back into voting for creators using their digital application on the steem blockchain. In fact, by necessity, all of it was used to that end (except for a few self-votes).
From the perspective of Steemit Inc., they probably would've preferred a more successful platform that would drive more traffic to the steem blockchain. Them's the breaks.
From the perspective of DLive, they had no obligation to anyone or anything. And if the developers had a personal relationship with the developers of the LINO blockchain such that they were/are willing to take their application to an unproven, not-currently-working backend, that's their business. Literally their business, such that they have the right and freedom to make that decision.
If what you care about is a proven application being associated with the steem blockchain, that all of this outrage directed at the DLive developers by the steem community is actively working against that end. After all, it may be that LINO turns out to be complete crap and in no way provides enough working capital in the long run to keep the business running. At that point they may want to consider coming back to the steem blockchain, especially if it's done well in the meantime.
If it was me, there would be no way in Hell that I would want to put my work and sweat back in front of a bunch of ungrateful bastards like that. No way in Hell. The steem blockchain would have to be burying XRP and Bitcoin and Ethereum would've had to burn to the ground for me to come back to the steem blockchain if I were getting the treatment the DLive guys are.
You want to make sure there's a lot fewer digital apps in your ecosystem? Because that's how you make sure there's a lot fewer digital apps in your ecosystem.
Which brings us all the way back to your original question, which is "do you have any suggestions for policy changes that might be effective?"
Assuming that the implied in the state goal is the improvement and expansion of the steem blockchain, I'd say "write off your loss with a laugh and make a better bet next time," because that's the only reasonable policy change that furthers the intent.
You're literally restating my observations on my first comment in expanded form but coming to the different conclusion.
Fair enough. I know for fairly certain that Stinc are not too happy about the lack of communication and I make my points in the spirit of heading off this giant entitled misunderstanding the next time. That means doing something different.
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.
⭕️
At least there's a little bit of wobble so that they don't make a perfect circle.
Some. A little. Mathematically elliptical.
You'll need calipers.
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?
This assumes that I think there's a problem with this activity, and that's an assumption without facts in evidence. In fact, just the opposite – I think that DLive making the choice to pursue what they think is going to improve the situation for them is both healthy and necessary for the growth of the steem blockchain, if that's something you care about.
They have a very data-intensive backend that is integral to the service they provide, and there are other services which would be equally data-focused, and we need multiple examples in order to determine if the steem blockchain is even a reasonable architecture for such a thing to pay for itself.
Bandwidth is not free. Hardware is not free. Time is not free.
The more competitors in a space, the better the we can determine whether or not that space is actually exploitable.
It may simply be true that DTube and DLive didn't have enough baseline differentiation to make a go of it in the environment provided by the steem blockchain. As an ecology, there simply may not be enough material that people want to engage with to keep multiple services afloat. It may be so that there aren't sufficient resources in play to keep even one service afloat, and now that DTube has another competitor that is seeing a tiny bit a traction (Vimm.TV), we may discover that another service finds it necessary to either shut down or migrate to another social media-esque blockchain as its notification backend. Which one it is remains to be seen.
But taking a broader view, all investment by a company in another company which is producing a derivative product carries with it an element of risk: the risk that said product will not be able to be sufficiently profitable to continue the project as it was. Steemit Inc., for all of its other failings, at least recognizes that and I would be somewhat surprised if they went on record in a significant way denigrating DLive for making a business decision that was profitable for Steemit Inc. for a solid year. That would be terrible business and it would create doubt in the minds of potential future application developers as to whether they want to invest their time and effort in a blockchain whose management organization would burn bridges after them.
Keep in mind, we are simply talking about delegation of SP, not any investment rounds, real money, any of that. Those sorts of things generally get tagged with contractual obligations in violating a contractual obligation is a legal matter. But we have systems for taking care of that.
As I understand it, the delegation of SP to DLive didn't come with any strings, at least any that anyone knows about outside of either organization. Likewise, neither did the removal of the delegation – because delegation is not investment in a reasonable sense. Delegation is just providing the ability for the person so delegated to work the levers of voting on the blockchain just like anybody else, only with bigger levers scaled to their SP. Effectively, Steemit Inc. didn't give any money to DLive by delegating SP, they just gave DLive the power to direct more money – and if you look at their reports on a weekly basis, which they produced and were very forthcoming with, the vast bulk of it was sunk right back into voting for creators using their digital application on the steem blockchain. In fact, by necessity, all of it was used to that end (except for a few self-votes).
From the perspective of Steemit Inc., they probably would've preferred a more successful platform that would drive more traffic to the steem blockchain. Them's the breaks.
From the perspective of DLive, they had no obligation to anyone or anything. And if the developers had a personal relationship with the developers of the LINO blockchain such that they were/are willing to take their application to an unproven, not-currently-working backend, that's their business. Literally their business, such that they have the right and freedom to make that decision.
If what you care about is a proven application being associated with the steem blockchain, that all of this outrage directed at the DLive developers by the steem community is actively working against that end. After all, it may be that LINO turns out to be complete crap and in no way provides enough working capital in the long run to keep the business running. At that point they may want to consider coming back to the steem blockchain, especially if it's done well in the meantime.
If it was me, there would be no way in Hell that I would want to put my work and sweat back in front of a bunch of ungrateful bastards like that. No way in Hell. The steem blockchain would have to be burying XRP and Bitcoin and Ethereum would've had to burn to the ground for me to come back to the steem blockchain if I were getting the treatment the DLive guys are.
You want to make sure there's a lot fewer digital apps in your ecosystem? Because that's how you make sure there's a lot fewer digital apps in your ecosystem.
Which brings us all the way back to your original question, which is "do you have any suggestions for policy changes that might be effective?"
Assuming that the implied in the state goal is the improvement and expansion of the steem blockchain, I'd say "write off your loss with a laugh and make a better bet next time," because that's the only reasonable policy change that furthers the intent.
You're literally restating my observations on my first comment in expanded form but coming to the different conclusion.
Fair enough. I know for fairly certain that Stinc are not too happy about the lack of communication and I make my points in the spirit of heading off this giant entitled misunderstanding the next time. That means doing something different.