3 ms·
I never said it was a reason to. I simply said this method is anything but simple, as the author called it. Your method would require even more potential lines
by genericuser 12y ago
I never said it was a reason to. I simply said this method is anything but simple, as the author called it. Your method would require even more potential lines on the monthly report than the nearly identical method I described above. As yours would require a per user line, even though many of them would have duplicate rates.
Keep in mind things would still need to be split per song also, as rights holders vary per song.
Do you really think giving every artist that many potential lines of accounting every month can be called simple?
- ignostic 12y agoExactly. Based on data from Spotify[1] and taking an average payment[2] of $.0052, I calculated Spotify would be storing about 20 BILLION accounting records PER MONTH. Showing my work: 15m paying subscribers = ~150m per month, ~105m paid to artists @ .0052 per song = 20.154 million songs in a month. [1]https://press.spotify.com/us/information/ https://press.spotify.com/us/information/ [2]http://thetrichordist.com/2014/11/12/the-streaming-price-bible-spotify-youtube-and-what-1-million-plays-means-to-you/ http://thetrichordist.com/2014/11/12/the-streaming-price-bib...
- ricardobeat 12y ago20 billion records per month is still reasonable, there are hundreds (maybe thousands) of businesses storing a multiple of that amount of data daily.
- Dylan16807 12y agoSo your argument is that it's unreasonable to store a list of every song play, even though they already do so? Or that it's unreasonable to make them "accounting records"? Not a problem. They aggregate using the current method to limit the number of "accounting records", they can aggregate just fine using the new method. Have "accounting" start with revenue per song the same way it used to start with listens per song, after asking the database to process its 20 BILLION records.
- Dylan16807 12y agoThe model is extremely simple. The number of formulaic, near-identical lines on an arbitrary report has nothing to do with complexity. Splitting per song already has to be done. This just gives you a different amount of money to split per song with the existing mechanisms.
- genericuser 12y agoImplementation and adoption are part of the complexity of a solution, in my book at least. I assume those who do not consider implementation and adoption part of the complexity have either come up with genuinely simple solutions to problems or never had to complete those portions of the task when they were not simple.
- Dylan16807 12y agoImplementation is one paragraph of SQL or statistical code, given access to the data set and a few minutes to execute. This change in how revenue per song is calculated is truly simple. The only hard part is convincing people it's better. Adoption has nothing at all to do with complexity. Be careful you're not moving the goalposts. Bill gates giving me a billion dollars to screw around with is extremely simple, and also will never be adopted.
- genericuser 12y agoAdoption is directly effected by the implementation and design you choose. If your app is nothing more than a table and some aggregate statistics, because you just made the simple implementation with absolutely no design, then good luck getting musicians especially older ones who probably still rely on paper copies of their monthly records being gasp mailed to them to adopt the app. It is not moving goal posts its considering whether the 'solution' will actually work given circumstances outside the technical feasibility.
- Dylan16807 12y agoThe old method mailed them revenue taken in per song. The new method will do the same. You mail them the same sheet as before, but it's probably more fair.