Legal/Government
Alternative Compensation Systems
Aaron Swartz's post about the Alternative Compensation System fleshes out some of his prior ideas and musings about a fair system for rewarding artists. I'm glad to see that some serious thought is being put into this issue.
People with broadband Internet connections pay an extra $3-$5 on their bill (the amount is calculated by determining how much money is lost by Internet downloads and dividing it by the number of Internet connections), which is given to the operators of the system ("MiniPay"). (Optionally, a similar charge can be added to other Internet connections, blank media, burners, computers, etc.) In return, they receive a "blinded signature token" that allows them to tell MiniPay what they're listening to without cheating (the token can only be used once) and without knowing who submitted it (the ISP was "blinded" when it gave it out, so they don't which they gave to who). The token is sent to them automatically and electronically and is held onto by their MP3 player (e.g. iTunes).
. . .
Yes, this is one difficult problem, but there are some ways to mitigate it.
. . .
Third, a variety of technical means could possibly be used to make faking playcount data difficult for the average user.
. . .
Yeah, this is a hard problem.
. . .
Perhaps the best thing is to include some quickly-updated anti-virus software with all playcount collecting software so that any such virus can be quickly contained.
I have a few reservations about this proposal.
First, this solution is designed to cope with the advent of the Internet. However, top down models don't work so well on the Net. In general, models that work in a brick-and-mortar system don't work too well on the net (eg the .com boom and many of its transplanted business models). The chaotic nature of bottom up systems (the net, P2P, weblogs) lend themselves as good solutions to hard problems. Harder problems can be solved by using lots of tools that specialize in solving one hard problem. ACS is descibed as having several hard problems to solve and having one solution all these hard problems is failure prone.
Second, the fix for the music industry is not another company or a government institution. The RIAA/MPAA has muscled its way into the most lucrative siutation possible and they will do the same in ACS. If this is even permitted to pass by the RIAA, (I doubt it) they would demand to have a hand in it. If we're trying to avoid the RIAA and its tactics, we need to create a new model where the RIAA is superfluous, and thus easy to set into the dirt. Central organizations have failed us on the net -- take Network Solutions as an exampole.
Third, if attacks need to be mitgated, the underlying model is flawed (e.g. Internet Explorer). Models that balance cooperation with competition are likely to work better than models that have lots of weaknesses to attack. As an example of an attack prone model, take PayPal. PayPal is an easy target for crooks since it deals with a virtual representation of cold hard cash. In order to start making money, PayPal needs to have gazillions of transactions a day -- otherwise the fraud related aspects (prevention, investigation, resolution) of the business take too much money to earn any at the end of the day. To avoid this. it's better start with a model that works. It seems like mediAgora is a step in the right direction.
Finally, let me espouse a favorite quote from one of my CS teachers: "Complexity is a scarce resource". Meaning, you can make your system only so complex before you start having problems. As an example take Windoze and IE -- they are too complex and thus riddled with bugs.
This applies to the ACS -- it seems too complex already and it hasn't really solved the hard problems yet. Not a good sign. So, Aaron, I urge you to simplify, simplify, simplify -- Keep It Simple Stupid!
Posted by Mayhem at December 17, 2003 04:56 PM
Simplicity:
Recently had a conversation with some folks about simplicity vs complexity.
Summary: To reach simplicity, one typically finds an elegant solution to a problem. The difficulty is that one really needs to understand the problem before you even has the possibility of coming up with said elegant solution.
At work, the product we've developed is an incredibly complex system. When you sit back and look at all the original design documents, a great many of the decisions made were to make things simpler. But all told, dozens and dozens of small simple bits still add up to an incredibly large and complex system.