I think a lot of developer tools come with exactly the type of statement the author is looking for--"what the developers were thinking when they designed it...the assumptions that were made about how the program should be used." I too would also enjoy it if people started doing this for ordinary software as well. But I think I know a reason why they don't.
The author raises the example of Microsoft Word, so let's imagine we were going to write such a statement for Word. The problem is that we'd end up writing something that would piss people off. The author says this: "Why is it so much work to change the fonts in a paper written in Word? Because you shouldn't be setting fonts directly; you should be using paragraph styles to signify your intent and then make visual adjustments later." But when I look at word's interface, it doesn't look like word was designed with that philosophy in mind at all. He's right that using styles instead of setting fonts directly will make it easier on you later, but that clearly wasn't Word's philosophy.
If you want to directly change the font or style of just the one piece of text you selected, there are multiple toolbar and menu widgets, highly visible and available, as well as multiple shortcut keys. In office 2007 they added the "live preview" feature to make it really smooth while you're doing it. They clearly went out of their way to make these types of direct changes really easy and really discoverable.
On the other hand, if you want to define a new style, or change one of the styles that is already defined, you have to do through multiple layers of nested modal dialog boxes. Once you have done this, using the style is made easy and highly available (lots of ribbon space, etc.) But again, the easy action is a purely local action--it operates on only on the text selected.
So to me it looks like word's philosophy is: you should be able to visibly see ALL the results of what you're doing right as you do it. Anything that violates this rule gets set aside in a dialog box so that the ordinary folks won't hurt themselves with it. That can make things really frustrating when you're editing a large document and want to keep things consistent across it, but they'd rather make their tool easy to understand upfront, even at the expense of larger scale advanced use. Other tools that are intended for mostly professional use, such as Photoshop, make the opposite choice--they allow their interface to be less obvious at first in order to make it easier to use at an advanced level.
The kind of philosophy statement the author is looking for would end up making that type of tradeoff pretty obvious, even if it managed to avoid stating it explicitly. And most people won't want to do that when they're thinking from a marketing perspective. They never want anything that states, or even too strongly implies, that their tool has a drawback--even if it's one that was accepted on purpose to get a better benefit elsewhere. I'm not arguing that this is (or isn't) the right way to approach marketing--but I can say it's easy to observe this mindset across many different fields, including our own.
I'd really like to see that comparison as well. And wouldn't Pandora and Spotify, like radio, be a channel to expose people to new music that they then might buy? Personally, Pandora has worked this way for me multiple times--they'll play a track that I haven't heard before and like, and I'll go to Amazon and buy the track or sometimes the whole album.
In the days when a few radio stations were the only free mass distribution channel, this exposure was so valuable that bands or their labels would actually pay the radio stations substantial sums to have their songs played. This was known as "payola," and was viewed as a crime, for reasons that are still a bit unclear to me.
I once was hospitalized and got an x-ray while on a trip. They gave me a CD with the images on it, which I took to a different doctor (not affiliated with the hospital that gave me the X-ray) in my home city later. When the doctor put the CD into his Windows machine, I was shocked to see that it used AutoRun to run an image viewing program stored on the CD! My doctor was not at all surprised to see a totally unfamiliar program running on the same machine that he uses to access all of his patients' medical records, create perscriptions, etc. He told me this was the normal way to share images in different formats across hospitals. (I actually helped him figure out how to figure out the clunky UI of the image viewer.)
Having seen that, I can't say I'm surprised that medical computers of all kinds are full of malware. For all I know, I might have carried a computer virus from the hospital onto the doctor's office computer myself! I saw no sign of that, and the viewing software looked legit (even if it was clunky and hard to use) but viruses that attach to legitimate programs and hide from the user are not new. I hope this changes soon.
> When I buy software, I don't only buy into the software I get, but I support it because I think it has a bright and better future.
Eric S Raymond made this point in "The Manufacturing Delusion" (http://www.catb.org/esr/writings/homesteading/magic-cauldron...). The value of software to a user lies more in the expected future value of updates than in the immediate value of using the software. This is true regardless of whether you pay for the software up front, and regardless of whether you expect to pay for the updates.
I would add this: the cost to a user of software is also much more than its price. To use software means investing time and effort into it, regardless of whether you paid any money for it. Then, as time goes on, you come to rely on the software's presence--you build your habits around the assumption that it is available, and bear the risk of disruption if it suddenly isn't. These hidden, non-monetary costs can be far larger than the monetary price paid, if any.
The problem is that the implicit non-monetary costs on the user side do not represent any benefits for the developer. That the user invested time and took risk doesn't give the developer anything--they only gain the explicit monetary price. But the implicit future benefits expected by the user DO translate directly into future costs for the developer--just as much as the present benefit corresponds to past developer costs!
So there is a big mismatch between what people intuitively feel they are exchanging. On the developer side, Matt Gemmell's comment quoted in the article feels right: "you paid, you got software." But on the user side, the story feels like "I spent time and wrapped my habits around this software, in expectation of its continued improvement, then found out to my surprise that no improvement is coming."
That said, I don't have any new shiny ideas on how to solve this problem. In the end, I agree that the developers of Sparrow owe the users nothing. But I also see why the users are reacting as if somebody took something away from them that they thought they had.
