FOSSLC Panels and Me
Thursday, 16 April 2009
Posted by austin in: Technology, Toronto, comments closed
I’ve been extraordinarily fortunate recently to be invited to participate in two panels presented by FOSSLC and hosted by the University of Toronto.
The first panel, held on the 31st of March, was about participating in the Google Summer of Code and my experiences as a mentor. With me on the panel were Diego Novillo who works at Google on GCC; Blake Winton (@bwinton) who mentored for DrProject; Nelson Ko who mentored for Tiki Wiki; and Behdad Esfahbod (@behdadesfahbod)who was in different years a student for, a mentor for, and an organizer for the GNOME Foundation. It was a lively and informative panel, and I think a lot of interesting things were said.
The second panel is what FOSSLC calls a “Leaders panel discussion”, taking place next Wednesday, the 23rd of April. I’m going to be participating with some fascinating people (not everyone is yet listed on the page) and I’m looking forward to it. The questions haven’t been decided yet, but I think that there will be interesting things said.
Fixing a problem with hald on Ubuntu 8.10
Monday, 16 March 2009
Posted by austin in: HaloStatue, Technology, comments closed
Saved for my own reference as much as anything. I was having a problem this morning on my Ubuntu x86-64 where I was getting nothing but a spinning cursor (the busy cursor) where I should have seen gdm. The problem was the HAL daemon (hald) wasn’t starting and I couldn’t figure out why. After digging through several bugs, this gem presented itself, and I tried the changed gdm script. It didn’t fix the problem, but when I ran “lshal” by itself, I got:
lshal: symbol lookup error: /usr/lib/libgobject-2.0.so.0: undefined symbol: g_regex_unref
This helped me find a reference on slackware-italia.com that helped me solve my problem: my ld.so.conf.d had no reference to /usr/lib, only /usr/local/lib. I added it and all is well.
GNU GPLed Software and the iPhone
Tuesday, 26 August 2008
Posted by austin in: Apple, Technology, iPhone, comments closed
Last month, Aristotle Pagaltzis claimed that “John Gruber doesn’t understand freedom“. This is in response to Gruber’s post about the release of the WordPress iPhone application source code.
Unsurprisingly, Aristotle is probably wrong, as is the FSF. Their own history with respect to running applications on non-GNU GPLed operating systems suggests this. I’m going to briefly address Aristotle’s comments in regards to the FSF’s definition of “free software”1.
The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.Study? Yes. Adapt? Technically, with the source code, yes, except, without a developer key from Apple the most useful thing I can do with the changed source code is print it out and use that as… toilet paper.
On many Unixes, compilers were an added cost. This still remains true on some platforms (and gcc isn’t an acceptable replacement on some platforms). Without access to a compiler, the most useful thing you can do with the changed source code is, as Aristotle says, toilet paper. Note as well that there’s still the “Operating System exception” in the use of the GNU GPL. Specifically, I can use any services or libraries provided by the operating system without infecting the operating system or the GNU GPLed software that I’m compiling.
You may as well complain that the development toolchain requires that you purchase a Macintosh computer to write an iPhone application, since there’s no version for Windows or Linux. (Nor is there likely to ever be.) I see the requirement for a developer key as analogous to the requirement of a compiler and easily falling under the “Operating System exception” for execution purposes.
The freedom to redistribute copies so you can help your neighbor (freedom 2).As long as my neighbour is the App Store, I suppose.
You can still do this, either through ad hoc distribution or through Apple’s own system. You can also redistribute the changed source without limitation. The GNU GPL says nothing about requiring that distributions be binary distributions.
Being free to do these things means (among other things) that you do not have to ask or pay for permission [emphasis mine].
You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way [ditto].Uhm, except Apple, right? Right?
This is where Aristotle has gone completely off the rails with respect to iPhone software development.
As a license agreement, the GNU GPL does not impose—nay, cannot impose—requirements on third parties. This is partially the source of the “Operating System exception”; you cannot force IBM to release the source of AIX just because you build, run, and/or distribute a GNU GPLed piece of software on it. (If you want to write well-accepted software for AIX, you’re not going to use gcc; you’re going to use IBM’s xlC, which is really expensive.)
I can, without limitation, make modifications to the WordPress iPhone application and use it privately with my developer key. I don’t have to tell anyone that I’m doing this, at all. (My iPod Touch still has some demo programs on it.) I can also, without limitation, post my modified source (which, again, is all the GNU GPL gives a damn about) anywhere I want without telling anyone else anything about it.
What I can’t do, without going through the App Store, is publish a compiled binary for other people to use without having to effectively buy the compiler.
But none2 of my rights under the GNU GPL have been violated. Period. Because the GNU GPL just cares about the software in the abstract, not in a specific compiled form.
I guess those silly hippies at the Free Software Foundation were right.
I guess those silly hippies forgot to read their own licence and recognise their own history when it comes to their licence. You and I might prefer a more open App Store with fewer restrictions on what software can run and how it could be distributed, but nothing about iPhone software development violates the GNU GPL, as much as people would love to pretend that it does.
Notes
- ↑1 This is 1984-style propaganda, pure and simple. GNU GPLed software isn’t “free”; it’s encumbered. Those encumbrances may be for a greater good, but stop lying and calling it “free”. There’s absolutely no need for that crap.
- ↑2 Yes, none. I can give you the .ipa file for an iPhone application if you want it; you just have no way to install it on your device to make it run. But the GNU GPL doesn’t require that I give binaries out at will, but it does require that the source be made freely available to recipients of binaries.
Rogers/Fido, the iPhone, and Me
Saturday, 28 June 2008
Posted by austin in: Apple, Technology, Toronto, comments closed
I’m a happy customer of Fido. Even after Rogers bought them, they didn’t ruin them.
Now, Rogers has the iPhone. And the best data rates that they’ve come up with are absolutely insane — with no unlimited data and that we should feel that their plans are “High Value”.
Colour me not interested. Here’s the text of my feedback to Fido:
Thank you for showing that Rogers is both stupid and greedy. I had planned on getting an iPhone in two weeks. Now I will NOT get an iPhone because of your absolutely insane data pricing. You call it “High Value” pricing; I call it “highway robbery” pricing. When AT&T has a better price plan than you, it strongly suggests that you’re out of touch. Let me know when your prices return to Earth with an unlimited 3G plan and I’ll happily upgrade to the iPhone.
I should have pointed out, but did not, that I have no problem with the idea that I have to spend $75 or more per month—I’m already spending a lot of money. But I want value for that money, and Rogers plans are anything but value to the consumer. They’re a pure rip-off.
That said, there’s a petition on-line that I refuse to sign, mostly because I refuse to have my name associated with some of the disgusting things (including wishing Ted Rogers bodily harm). I may think that Ted Rogers is a greedy pinhead, but we should act civilized, people. Grow up.
Common Craft Explains Twitter
Wednesday, 5 March 2008
Posted by austin in: Personal, Technology, Twitter, comments closed
I love this explanation of Twitter from Comon Craft.
(Via Laura Fitton of Pistachio Consulting.)
I Paid for Twitterrific
Thursday, 27 December 2007
Posted by austin in: Apple, Technology, Twitter, comments closed
When Craig Hockenberry released Twitterrific 3 as either ad-supported or a $15 licence, I paid it immediately. According to one “Captain Marc” over at Odelbee, there’s a “hack” to disable the ads from Twitterrific, who apparently thinks that I’m a bit of an idiot for paying for Twitterrific. (Interestingly, between comment #9 and #21, Marc went from thinking that Twitterrific was a “POS” and a pretty good app.) “Captain Marc” is wrong: the switch from free to free+ads or paid wasn’t without warning; this was stated up front on the download page of Twitterrific.
He’s further wrong: Eudora was simply a tool for receiving and delivering … content
, yet it sold for quite a long time. Very few of the applications that I’ve bought for the Mac since I switched eighteen months ago have I had any qualms about buying after buying them, and Twitterrific is one of the apps that I use every day, multiple times a day. There are features I’d like to see, certainly, but it’s a damned good product and I’m proud to have paid for it.There’s plenty of software that I wouldn’t buy at full price; sometimes I’ve waited for bundles (and my unwillingness to pay full price has generally been justified by the lack of use the product ends up seeing). More often, though, I just stop using the product. If I use it, though, I pay for it. No ifs, ands, or buts about it. And so should you, “Captain Marc.” You certainly shouldn’t be posting hacks or alleged hacks.
More on this from Seth Dillingham and Justin Miller.
The Twitterrific icon in this post is copied from the IconFactory web site. It belongs to IconFactory and has been used with permission.
Optimize What?
Sunday, 25 November 2007
Posted by austin in: Apple, Ruby, Technology, comments closed
There’s been a furore recently over an article by Ankur Kothari where he optimized CTGradient. As an exercise in optimizing code, it was fairly aggressive but otherwise pedestrian. As an article, it was inflammatory and insulting from the beginning:
CTGradient contains an incredible diversity of built-in gradients, gradient styles… For demonstration purposes, all these features are excellent. For production, this is a nightmare.
It gets no better at the end:
…The documentation already shows you how to draw gradients, yet the number of applications using CTGradient – the whole 1300 lines of it – is astonishing.Please: When you use other people’s code, don’t put it in without a thought. Go through it, understand it, and optimize it for your specific need. For the better performance and reduced RAM usage, computers will thank you.
Quite legitimately, some Mac developers spoke out about this. Hoare’s famous dictum Premature optimization is the root of all evil
was pulled out early. It’s completely applicable here by any measure. This story would have ended here, and I wouldn’t be writing now, had it not been for a series of bile-filled nonsensical articles posted at Rixstep, starting with one calling Mac developers (such as Daniel Jalkut) objecting to this inflammatory article as the Landed Gentry of Mac Development™.
Which Optimization?
I’ve been developing software for a long time. While I haven’t done any Objective C programming yet, there’s nothing in Ankur’s article which is unique to Objective C. When developing software, you make it work, make it right, make it fast. In that order. The goal is to ship your software, not have it languishing in interminable development. Mac developers aren’t the only ones who will use third-party source without looking for optimizations (or further optimizations, as the case may be); Unix and Windows developers do this, too. Any developer worth their salt does this, because the first goal is to make it work. At work, when we see performance and memory issues, we don’t start digging through third-party code. We don’t even start looking at our own code. We start looking at profiled performance data. Then, and only then, do we start to make something fast.So, if the first goal of software development is make it work, what’s the first optimization you should do? You should optimize your developers’ time toward shipping the softare. Window background gradients aren’t the type of thing that will sell more copies of an application, but their absence may prevent some sales because the application doesn’t look “tasty” enough. So, you start looking at how to provide gradients. You see that Core Graphics supports it, and you start digging in the documentation and you see that it’s going to cost you lots of extra time to learn the CG gradient support. And then you have to debug what you’ve written. No sensible unit testing here; this is visual inspection. If you can add a single file that reduces your time to implement a background gradient—which you don’t really care about yourself but you know it’ll cost you sales not to have it—then you’re going to be better off entirely. Scott Stevenson of Theocacao stated it much better in 2006:
Ah. Now doesn’t that feel better? It’s not that the class does anything that is otherwise impossible, it’s just a lot cleaner because all of the goofy callbacks and whatnot are moved into their own code space. In other words, you have more free time to work on the actual application.
CTGradient is (almost) all about developer optimization. It also helps you deal with the second optimization: optimizing for correctness. It’s code that someone else has written and debugged. You know that other people who develop Mac apps are using it, and no one is screaming loudly about bugs in the code, so you feel pretty comfortable with it. So, you know that by using this drop-in library, you are not only getting this negative feature done, you’re getting it done right. At this point, you can forget about the getting it done fast, because no one has complained about gradient performance at this point, because you’re not yet done shipping.Make it work; make it right; make it fast. Optimize for developer time first (and this includes good design), and then worry about the rest when you need to.
More Code Optimization = Better Developer?
Things really went off the rails with this discussion when Rixstep posted the “Landed Gentry” article. He’s posted further bilious articles attacking some of the developers involved in the discussion over CTGradient optimization, but I’m not considering those articles for this discussion, since they’re pure bile and add nothing meaningful to the discussion (that is, they’re still based on false optimizations that I’ll address in a moment). In the “Landed Genry” article, Rixstep asks:
Who would you rather have engineer your software? Someone who’s as conscientious as Ankur Kothari? Or someone who squirms and attacks and insinuates and does the absolute utmost to avoid the actual question? You the user/paying customer can decide. Wander over to Ankur Kothari’s article on CTGradient and see who’s objecting. At least you’ll now know what the Landed Gentry of Mac Development™ think of you.
Rixstep presents a false dichotomy here. Ankur isn’t particularly conscientious in his article; there are specializations presented as optimizations, and some optimizations aren’t geared toward the most important parts of development anyway. Daniel Jalkut, on the other hand, is very conscientious toward his most important target: his customers’ time in using the program. I’d be very surprised if anyone was saying that MarsEdit is too slow because of gradient display.Optimizing on parts of code that don’t matter doesn’t make you a better developer. Optimizing the right parts of code at the right time do. If I were hiring Ankur and Daniel, I’d have to watch over Ankur more to ensure that he wasn’t working on stuff that doesn’t matter to the customer. Like optimizing gradient code without actually knowing that it was a performance bottleneck. Ankur does a decent job of making sure that the resulting code meets the minimum required needs of the job (which, if you’re developing from scratch is a good thing, after all, YAGNI). He outright says that one should spend time going through third-party code that (probably) isn’t relevant to the primary mission of your softwasre, and therefore doesn’t help toward “make it work.”In reality? They’d probably both work out as great developers. But Ankur cares no more about a user’s software experience than Daniel does, despite the insinuations of Rixstep. I do question Ankur’s judgement on the optimizations made and how they were reached, or at least how they were explained.
The Axis of Optimization
Let’s play along for a moment, though. Assume we have already determined that there’s a measurable performance problem and we don’t have any currently outstanding feature requests or other problems that are higher priority than this performance problem. Assume further that we’ve profiled our program and we’ve determined that yes, our source of program slowdowns is CTGradient.There’s a legitimate question about whether Ankur’s effort was really optimization or specialization. When he says Firstly, let’s remove the methods we know for sure we won’t need…
, the discerning reader should be asking why we don’t need those methods. Ankur doesn’t explain how he reached this conclusion. This means that the developer who is doing their job right won’t immediately think of eviscerating the entire CTGradient library, but rather measuring the performance characteristics of the library.Ankur made a mistake in his approach. Yes, simpler code is usually easier to maintain, debug, and will usually perform better. But simpler code does not necessarily mean better or more performant code. A bubble sort is simpler than quicksort; there’s no way that it’s faster. One may as well look at binary size for comparison. This isn’t to say that one shouldn’t strive for smaller binaries; the larger your binary, the more likely it is that you’ll cause something else the user uses to swap out to disk, which would be bad. Can CTGradient actively contribute to this? It’s not distributed as a Framework, so most projects compile it directly into their code.CTGradient’s 1,172 lines of code in six source files (as determined by Sloccount) doesn’t even come close to adding meaningful binary code bloat. I compiled CTGradient from the latest available SVN checkout and Ankur’s “Lean Gradient” project. I compiled both as Universal using the default settings and compared the final binary size (from Contents/MacOS/) and the intermediate object file sizes. Since the projects are structured differently, it’s not a completely fair comparison. Ankur’s binary does one gradient and results in a binary size of 42,992 bytes; CTGradient does a lot of different types of gradients and results in a binary size of 78,776 bytes, a difference of a mere 35,784 more bytes of Universal code. A lot of the binary size differences is overhead, though. CTGradient creates three object files per architecture: CTGradient.o (55,964 bytes), CTGradientView.o (14,160 bytes), and main.o (976 bytes), leaving an overhead slack of 7,676 bytes. optGrad just has main.o (10,912 bytes), leaving an overhead slack of 32,080 bytes. So, CTGradient.o isn’t going to add to your binary size overhead in any meaningful way.What about memory use? Ankur posted two follow-up comments that suggested that CTGradient adds between three and ten megabyes of memory use to a program over and above his approach. That suggests that there might be room for a CTGradientLite, but making that would require extensive profiling to determine the parts that could be excised prior to doing so. And, of course, if all you need is a single gradient like Ankur did, and have the time and mathematical knowledge to do what Ankur did, by means do so. Ankur’s five minutes, though, might be five hours for you—so make sure that you don’t have something more important you should be working on.
The Unwashed Messes
Ankur can perhaps be forgiven for the mistakes he made, as other posts by Rixstep suggest that he’s quite young. He hasn’t yet had to learn the personal interaction lessons that most of us have to learn, and that most of us do learn. There’s a few who don’t, and Rixstep appears to be one of these developers who resisted learning about how to behave toward other people throughout his career. He stepped into this discussion “defending” Ankur from the “Landed Gentry”, who were simply asking the same questions that any good software developer would. He’s gone further recently into personal attacks against two of the more vocal questioners. Reading further on Rixstep’s site, anything that is selling better than his software seems to result in that anything being called the “Landed Gentry” of something. He thinks that he’s defeating dragons, but in reality he’s tilting at windmills just as usefully as Don Quixote did.Rixstep is supposedly in the business of selling software. The content and tone of his posts have managed to do the opposite. I had recently considered purchasing some of his software; I know now that to do so would have been a mistake, because he doesn’t treat his peers well. It’s impossible for him to treat his customers well with that sort of attitude. It doesn’t take much to be generous in spirit to people, at least in starting. It doesn’t take much to realize that there are better ways to deal with conflict than has been done.There is a difference between taking a hard-line, hard-nosed approach to something and defending it on technical grounds and actively attacking someone without basis. Rixstep’s attacks, starting with the “Landed Gentry” article, are entirely without merit. Ankur didn’t optimize CTGradient; he made a specialization. This is valid sometimes, but in reality something like window gradients isn’t central to your application’s purpose, and to spend more than an hour or two dealing with them would be wholly inappropriate. The good developer knows that it’s better to ship than to spend all your time optimizing someone else’s code or rewriting it yourself.
Where does Ruby Fit into This?
The astute reader would have noticed that I filed this as a Ruby article as well. While I haven’t mentioned Ruby until this point in the article, the parallels here are obvious. Rixstep and Ankur both say that the dozens of applications that use CTGradient are abusing their users because it uses too much code, too much space, too much memory, and it’s too slow. Aside from the memory use, the claims have either been exposed as false already or haven’t been supported with data. As Scott Stevenson’s quote suggests, CTGradient optimizes for developer time.So does Ruby. I can get more written with Ruby than any other language that I use. It won’t be the fastest software, it might be a little more memory intensive, but I will get it written—and written correctly—faster. And that, given that shipping is the goal, is important. When Rixstep rejects CTGradient without providing a more optimized yet equivalent functionality alternative, he rejects any developer-side optimizations in favour of hand coding everything, including using more expressive languages.I reject that notion. And so should you.
There’s a Ruby Debugger?
Wednesday, 31 October 2007
Posted by austin in: Ruby, Technology, comments closed
Yeah. My post title is a little over the top, but since I started using Ruby in early 2002, I can’t count the number of times that I’ve used the Ruby debugger. After all, how does one count the empty set?
This is not to say that I haven’t had to debug; it’s to say that where tests haven’t sufficed in helping me specify behaviour correctly, Kernel#p has helped me find what did go wrong so that I could fix the problem and add a test (where appropriate; PDF::Writer, for example, has no tests).
So I think that Giles Bowkett is right, even though I’d say that debuggers aren’t harmful; they’re pointless in a pointerless language.
I find that I mostly use the debugger in C/C++/C# for stack traces in any case. It’s a bit less painful with a good IDE, but depending on the nature of the problem that I’m debugging (especially one in a tight loop), I will usually add print outputs to a log file and debug based on those logs. Yes, even when there’s pointers involved (because it’s usually a binary search approach where I figure out where a pointer went bad over a large run).
Not Going Back
Wednesday, 24 October 2007
Posted by austin in: Apple, Technology, comments closed
John Gruber has it exactly right:
Windows lost a huge chunk of the nerd market. Nerd switchers, in and of themselves, don’t constitute a significant enough number of people to account for anything other than a tiny blip in Apple’s Mac sales. But nerds are the people who recommend computers to friends and families; it seems inarguable that there are an awful lot of nerds recommending Macs today who weren’t five years ago.
I bought my first Mac (15″ MBP) in August 2006. In some ways, I bought it two months too early; in others, I bought just at the right time (I needed a new home laptop). In that time, I have convinced my parents to ditch their two Windows computers for a Mac—my MBP, when I upgrade early next year; I have told my wife that her next computer when this one dies will be a Mac and I have recommended Macs to three other people. There’s very little that one can do on Windows that one can’t do on the Mac; the only compelling reason for most people is games.
If you’re a big player of FPS games, you want a Windows PC. If you must always have the latest and greatest video card, you want a Windows PC.
Anyone else? You want a Mac. No, Apple doesn’t offer a $400 Mac. If that’s your budgetary limit, you *still* want a Mac, but you can’t afford one. Look at one of the Linux vendors. Because you’re not going to run a decent version of Vista on that $400 PC. And you’ll need to replace it sooner than you would an equivalent Mac. My rule of thumb for non-Mac hardware has been that you’ll get about 12 – 14 months of meaningful use per $500 you spend. I suspect that it’s 18 – 24 months of meaningful use per $500 you spend on a Mac. By meaningful use I mean before you start noticing memory and graphics limitations requiring significant hardware upgrades to keep up to date.
I’m not going back. I don’t know that I’ll stay with the Mac “forever”, but at this point, it’s the best computer investment that I’ve made so far. Aside from that first computer (and it was my dad’s investment then), that started me on the road I’m on.
More on the Wrong Question
Saturday, 20 October 2007
Posted by austin in: Apple, Technology, comments closed
In the comments of my previous question, John asked “what was the wrong question that he asked?” To which I replied:
The wrong question is the comparison between Vanilla Ice and Soulja Boy. Vanilla Ice was low rent back in the day — his second album was a live version of the first album, and his “superstardom” lasted about a year. Soulja Boy’s rap may be better than Vanilla Ice’s rap, but it’d be better to compare Coldplay or Oasis (people with more than one album to their name) to The Beatles or Pink Floyd when asking whether the singles price on iTunes is good, or whether they should be variably priced.
Radiohead may have hit on the right way to handle variable pricing, but that only works when you know you’re sending the majority of your money directly to the band. Most people don’t want to make the soul-suckers at the labels any richer than they need to be.
John replied last night with:
interesting — i read that differently. soulja boy is currently listed as one of the top 10 downloaded songs on itunes, which gave me the impression that his point was about demand. (right now, lots of people want that new hit single, and far fewer people want the old single that now sounds like crap.)
so i thought it wasn’t about which musician was “better” — i don’t especially like either of those songs, personally — but about which musician’s product was currently more “in demand.”
The record execs want you to think that it’s about demand, but it’s not. Demand pricing makes sense when there’s scarcity and you have a lock on the market. Newer music is anything but scarce. You can hardly go anywhere without hearing it as a ringtone, an advertising jingle, or just on the radio. I listen to a “classic rock” format station, yet they’re playing new music from Neil Young and Kim Mitchell, and they consider U2 (up until All That You Can’t Leave Behind, at least) classic rock. So music has the opposite problem of scarcity; there’s a glut.
The radio brings up another important point—as much as record execs would love to pretend otherwise, they’re not competing like you do in other markets. They’re competing against free. There’s plenty of songs out there that I like, but that I don’t like enough to even consider buying even at 99¢—not when I can hear them periodically on the radio. And if I wanted them, but they were more expensive than my lowest willing price, I can usually find them somewhere online. (I don’t; but I have used AllofMP3 before. I already pay the CRIA something every time I buy blank media, so I have the right to get songs that others share that way.)
There is one other theory the record execs could be using here, which is the concept that one values something one has to pay for. Therefore, one values something more that one has to pay more for. If this had been possible when Vanilla Ice was in his (short-lived) heyday, people may have been willing to pay $3.00 for “Ice Ice Baby”, but how many people would have regretted it later and deemed themselves fools? (The song has not aged well.) So the value of a song isn’t really derived from how hot it is, but its longevity. And even then, you’re still competing against a model that treats songs as essentially valueless (radio or satellite radio).
So, demand pricing doesn’t work well if there’s no scarcity (or artificial scarcity). We also know that subscription pricing for portable devices doesn’t work. (More accurately, it doesn’t work for portable devices where you control the content. Satellite radios are portable, but you don’t control the content.) Subscription pricing works when it gives you a menu of things to choose from (cable television, satellite radios) but the value is provided by the menu, not the individual pieces that make up the menu. (The subscription price is too low per person for the individual songs or television shows to be worth much at all. In aggregate, they can make money, but individually they’re fractional pennies value.)
What does work? That’s where we get back to the Radiohead experiment. They asked people how much they value their music. Some folks bought it for the absolute minimum; others paid much more. Most paid about the same price that they’d pay on iTunes. But you have to have an environment where that will work, and I don’t think that the Radiohead experiment is generally applicable for the entire catalogue of some bands’ music. (That is to say that I think that it’s a decent short-term strategy when the music is new, but I don’t think it’s sustainable for more than a few months.)
I don’t agree completely with Apple’s iTMS policy (you can have some songs album-only, but you can’t have an album-only album), as I’d love to see album-oriented rock make a return. (But I’d also love to see sound-bite politics go away.) I think, however, that the simplified pricing models make a lot more sense than pretending that something is more valuable because more people want it, when there’s no scarcity involved.
Souljaboy may be hot. Will he be next year? Or will he be dropped like Vanilla Ice?
