It seems in every version of Amarok 2 we have released there is at least one comment that sounds something like:
"But, the best feature of amarok 1.4 is still missing! Without --Insert one of the zillion and a half features Amarok 1.4 had-- Amarok 2.0 is useless!"
It is interesting for me to observe just how many "best features" Amarok 1.4 had, and also to observe exactly how many different ways Amarok was used. One of the issues with Amarok 1 development was that Amarok was trying to be a jack of all trades, and not really mastering any of them. This was well and good for the average Linux user, many of whom, when Amarok 1 was originally created, had no problem digging into the source to add their own little tweaks, features, or bug fixes. However, it is a problem for people that just want to listen to music, and leave the text editors and compilers at the door. With Amarok 2, our goal was not just to have features, but to perfect them.
To perfect features, we needed to limit our scope. Amarok 1 included a lot of dump-and-run code, where a large feature was submitted by an interested user, the code was committed and shipped, and then we never heard from the author again. This was the case with many of the media devices, and many of the engine backends.
We rely on phonon in amarok 2, so the engine issue is no longer one we have control over, although we are suffering from the results of incomplete phonon engines. While it is all sorts of nice to get backends for windows and mac for free, they come with many issues still, and we are constantly closing bugs reported by users that use the gstreamer phonon backend, as it is extremely buggy and incomplete. Unfortunately, many distributions ship this by default (due to patent issues) and as a result Amarok gets a reputation as being a lot less stable than it actually is on these distributions. Hopefully this issue is resolved in the future.
With regards to portable media devices, the ball is still in our park. Alejandro (xevix) had a summer of code project for portable media device support, and is working now on generalizing the code so that it will be fairly simple to add new devices. The shared infrastructure that Amarok 2 is built on (The Meta/Collection architecture) provides a familiar interface, so that even if Alejandro runs out of time (or interest) in the future, the code will be clear and understandable to whoever might pick up the pieces. The next step will be to readd additional media devices to Amarok 2 using this infrastructure. This should happen for 2.1 or 2.2, depending on various factors.
As we are constantly being reminded, perfection is not a fire and forget process. Code constantly improves (we hope) and mistakes we made in previous versions influence the next iteration that comes. This is quite visually apparent with the playlist. The Amarok 1.4 playlist was incredible to many people. It had a a lot of functionality and all sorts of nifty features, but at the same time, it was entirely unmaintainable by the time Amarok 1.4 ended. See this file if you don't believe me. For Amarok 2 we knew the playlist was important, but we wanted to start over, using the new model/view features in Qt4, and make it look more visually appealing. Ian's adventures are well documented. Nikolaj's adventures leading up to 2.0 were also well documented. The system that was created for 2.0 was a far cry from perfect, (the various paint methods made me cry on more than one occasion) but it was an important step on the road to this whole perfection thing. As Nikolaj more recent blogged, Amarok 2.1 is moving a lot closer to the ideal. I'm sure it will have issues, but with testing and use it will hopefully evolve into what we originally intended, a kick-ass feature that puts the Amarok 1.4 playlist to shame.
This has wandered pretty far afield from the point I didn't start with, but I suppose what I'm getting at is the same thing that we keep saying, and because I like to hit dead horses, I'll say it again. Amarok 2 is going to have many of the best features that Amarok 1 had. It will not have all of them. Our goal is to make a music player that is fun and enjoyable to use for a majority of the people. If this means omitting some esoteric features, then so be it. We also want a product that is fun and enjoyable for developers to work on, and that also provides incentive to not include the "fire-and-forget" code that composed many of the less-central features of Amarok 1.
