Thoughts on a New Tune

04/09/2010

I was on vacation last week, so I wasn’t around for the “big announcement” at work.

After returning yesterday and having had some time to catch up, I had a couple of personal thoughts I wanted to express about the whole situation.

The normal caveats apply1,2,3,4, but I also must point out: I’ve been doing build/release engineering on Linux my entire career. I started using Linux in 1995. I’m president emeritus of the Silicon Valley Linux Users’ Group. So I’ve uh… “been around for awhile.” I “get it.”

On the Discourse

One of the things that has been most disconcerting to watch is how some—not all, but some—extremely vocal Linux users have muddied the discourse to the point that the discussion is mostly a swamp now.

As a longtime Linux user5, I’m used to it6. But for people that aren’t used to… “lively” open source discussions, such invective is not only counterproductive, it reduces their desire to spend mindshare on Linux and it makes them associate such bad behavior with an entire community.

That’s a real shame.

Linux users need to engage in ways that increase the platform and community’s mindshare for others. This is especially true for those that are unfamiliar with open source. And when our brethren aren’t acting that way, we, as fellow Linux users, need to call them on it.

It doesn’t help. And ultimately, it won’t get the community what it wants.

On the Platform

Let’s face it: Linux is a difficult platform to support. I say this as someone who’s been using and administrating it for fifteen years and whose first job out of college was developing and maintaining Linux packages7.

Software development shops can easily spend an entire engineers’ time developing, building, and maintaining .debs, .rpms, .tar.gz‘s, .ebuilds, and all of the other various Linux packaging formats… and someone would still be unhappy that there wasn’t a package for their particular platform. For smaller shops, this type of investment is a nonstarter.

Testing those packages is equally difficult, because of the myriad configurations that users can put their machine into8. One way for those shops who really do want to support Linux to reduce this matrix: using qualified, known libraries and shipping those with your application. But in the good case, this is frowned upon; in the bad case, distribution in the packaging repositories is outright refused.

Linux additionally provides the burden that its various incarnations are so fragmented; even in cross-distribution packages (like .tar.gz‘s), various features can fail to work as expected because of decisions that distribution maintainers made which fit their requirements, but conflict with someone else’s.

Contrast this with the story on Win32 and Mac: the configuration matrix is smaller, and both Apple and Microsoft9 put vast amounts of engineering effort into backward compatibility efforts, even to the point of emulating bugs.

This isn’t to say Linux is worse or better than those platforms; it’s just different, and largely due to its history and the Unix model. So I’m not making a value judgment, other than to say supporting Linux is often more costly than supporting other platforms, due to the nature of the platform itself and its various permutations.

On the Situational Realities

Because the support issue was always complex, we weren’t doing a good job of producing what Linux users really wanted: packages in their own distribution’s packaging repositories, sanctioned by their distribution10.

So we provided the next best, reasonable thing: a tarball. But it’s still not what Linux users really desired, and understandably so.

Really, the announcement wasn’t a change as much as an admission that the current situation is a reality. Linux, as a platform, generally always gets less developer attention and features, largely because of the user base and mindshare issues. It’s just a reality of the platform.

In our case, we’re still doing nightly Linux builds, right along with Mac and Windows, and releases are very likely to have tarballs posted for users to download.

So materially, the actual steps that I, a Songbird user on Linux, will do to obtain and use Songbird will be the same for the next release11 as it has been for the last eighteen months: I will go to the website; I will download a tarball; I will install it onto my Gentoo box; I’ll start it up.

It’s true that I might run into a bug or other issue that isn’t seen on another platform, but that’s always the case, with any platform. In that case, I’ll file a bug. Like I always did.

So if one looks at the actual, material changes, they aren’t… huge.

On the Fork

One positive outcome of the announcement, I believe, is that people are engaging more than we’ve seen in the past.

When the iPod addon was “community sourced,” many people repeatedly said they wanted iPod support… but no one identified themselves to sign up for doing the work12

This is in contrast with some in the community who’ve announced a fork of the project, and who are organizing to fill a niche they see is currently lacking.

Honestly, I think that’s a good thing.

As they’re organizing, many of us are helping out and offering advice where we can.

This is exactly how it is supposed to work, and it’s very heartening to see people who really care about Songbird step up and try to help in real, measurable ways.

Having said that, it’s too early to know whether the fork will find itself akin to egcs13 or “just another open source fork.”

Having seen open source projects fork in the past, some advice for the new fledgling ornithological variant:

  • Forking is an extremely heavyweight solution. This is not to say it should never be done, but it requires a lot of commitment and effort, and there are often other, lighter-weight solutions that involve communicating, asking questions, listening, and bargaining.15
  • Be careful to not get too bogged down in the details; certain things are very important, but it’s super easy to get stuck on things that, in the end, turn out to not matter that much16
  • Be careful to not get caught up in pet bugs that don’t address the community’s needs17
  • An open source project, like any organization, does not have infinite resources; making hard tradeoffs is often not an entirely well understood aspect of open source projects, but it’s a necessary one.

In the end, I wish the new project lots of luck and look forward to working together for the mutual benefit of all of Songbird’s users, whatever form those users take.

And to my fellow Linux users: yes it’s true that changes are afoot, but we haven’t forgotten about you. Remember the next time you feel the need to voice your opinion on this development: many of us are you…

At the end of the day, we all want what’s best for the ‘Bird.

___________________________
1 I do not speak for my employer
2 I am not a lawyer
3 I am not an accountant; this is not tax advice
4 Blog post not valid in Tennessee
5 And a Gentoo user, at that!
6 Despite the fact that as I get older, I, too, find the ideological posturing tiresome
7 RPMs if you must know
8 To open source’s credit, this works remarkably well in practice, for such a huge testing matrix; but I believe it does so due to the higher efforts put in by most Linux developers/users
9 The latter significantly more than the former
10 There are many reasons for that; for anyone who’s dealt with it, it turns out to be a wicked problem
11 And the release after that, and…
12 There is one person that I know of who did try to get it building
13 Which was forked from gcc and later merged back to become what we all currently think of as “gcc”14
14 Which actually stands for “GNU Compiler Collection”
15 It turns out this is true of most organizations, but it doesn’t generally happen enough in open source projects…
16 Color schemes, logos, version control systems, etc.
17 Of course, finding out what those are is… a different issue altogether