Entertainer Releases Today!

Today, Entertainer makes our first (rather crude) release. There are lots of known problems with the codebase, but we thought that releasing early would give us the flexibility and users that would file bugs and help us get the ball rolling faster. The 0.1 release of Entertainer can be downloaded here.

A special thanks goes to Lauri Taimila for starting the project, Joshua Scotton and Matt Layman for sticking with me through the quiet issues, and Michael Charclo and Jamie Bennett for jumping onto the team and hitting the ground running. Without them, there never would have been a release today.

Six months ago, when I joined the project, I never realized it would take as much work as it finally ended up taking. It required concentrated efforts, good tools, better developers, and great alpha users. It feels now as though the stars aligned, the tides were at bay, and a squirrel somewhere in Saskatchewan, Canada farted in just the right way for everything to fall into place in just a short amount of time.

Launchpad was the catalyst

After all of this reflection, I realized something quite important. Launchpad is THE reason for this release. It couldn't have come together as well as it did if we had still been using Google Code. Google code was great, but we encountered lots of problems making LARGE changes, and causing headaches for everyone else. Using bazaar, the headaches were fairly localized.

About three weeks ago, I went through all the bugs on Launchpad, and prioritized them all, adding a few to the milestone 0.1 release, and sending an email out to the mailing list stating that the bugs marked needed to be fixed by the 14th of June, so we can release on that date. I'm proud to say that only one bug will slip, and it's a bug that we can do after the release in support of 0.1, instead of as part of 0.1.

As we migrated to Launchpad, I saw a great community seem to pop up around Entertainer at that time. It could be because of pre-release reviews that were being done, but as I looked more into it, I realized that by adopting Launchpad as our development tool hosting platform, we were adding our project into an area that was FILLED with people ready and willing to try out alpha software, file bugs, and be responsible for following up with those bugs. We had users we'd never heard of (with seasoned Launchpad accounts) show up to ask for help, file bugs, or just flat out say "Thanks for the software."

What Launchpad is to me

Many critics will complain that Launchpad isn't open source, and so it shouldn't really be an open source software hub as it is. I disagree. I think that all the neat features of Launchpad (code hosting, bugs, translations, blueprints...) play second fiddle to something greater: Community. The community is absolutely open. Want to see how Launchpad's existence helps bring the best Ubuntu releases possible? Head over to #ubuntu-bugs on Freenode two weeks before Intrepid (the next Ubuntu version) is released, and see the coordination between users that Launchpad provides.

So sure, (old and busted) Sourceforge, Google Code, Github, and the like may provide code hosting services, and some even provide bug tracking services, but shoot, how many of them can provide you with users? Better yet, how many of them can provide you with users who are patient with alpha software, willingly file bug reports without the use of expletives/flames, and follow up with you to see if they can help any other way? That's what Launchpad is to me. That's WHY Launchpad is to me.

I was looking through the bug list for Entertainer when I stumbled on issue #31. This bug must have come in during our sprint, and I just skimmed over it. I decided I would look into the bug, and was making a comment to go along with accepting the bug, This is where my personal reflection of 30 seconds started.

Initially, I thought, "well, just because it's the standard doesn't necessarily mean that it's the way we should go. Look at all these other apps that don't adhere to the standard." This didn't sound right, and my brain threw an exception. How many companies think that way, leaving the rest of the world to just complain. I caught the exception, and thought "well, we should review the standard, and see how well it is adopted now, and whether or not we should consider it now, or do it down the line." This also didn't make sense to me. How long do you wait before you implement the standard in your app? I finally rested on "We should jump at the chance to fall in line with standards."

Entertainer is an open source project, licensed under the GPL. This means that we're all about open standards as well, and making it easy for everyone to be compatible. If Entertainer, as an open source project, decides to go against those open standards, than we aren't that far ahead of proprietary software. I think every open source project should jump at the chance to adhere to open standards, and make it a priority. Then we can truly call our software "open."

This is big news. Apparently, AMD is promised to publish specs for cards >=R500 which is great news. I've been a fan of ATI for a long time, and I've even become a bit of an expert when it comes to the fglrx driver. I don't have any problem getting hardware acceleration to work on any of my boxes, but I've had to fight with it on SuSe and RedHat.

While I suspect that Dell had something to do with this, with their fancy shmancy Ubuntu Linux line of desktop computers, this is great news. If I thought for one second that the radeon driver would compare with fglrx driver (which it honestly doesn't), then I would have taken the free driver over the proprietary one. However, I'm not gonna cut off my nose despite my face in the name of "Free as in freedom" I'm a GPL kinda guy, but there's a limit to my fanaticism.

I am excited about this. However, a point was brought up on an IRC channel I frequent that while the GPU specs may be published, there are other decoders on the card for HDMI, DVI, and other encryption and DRM enforcements that most likely will not be published. Why? ATI is probably under a pretty strict NDA from their vendors. Although I'm not super familiar with HDCP, it also has engineering requirements which restrict the firmware on those cards, and can't be controlled via software, so no go for HDCP with any new drivers. Of course, I'm sure you'll be able to find something similar to the non-free repositories that we all go to for libdvdcss2 (which is illegal in the U.S. - come and get me...)

This is great news for the linux community though.

I've finally gotten around to finishing up the third version of The Iron Lion. It's been quite a pleasure to work with Django, and I've seen the light of a good python framework. I feel pretty confident in the work I've done for this site, and as such, I've decided to publish the source for it. There are some out of date tests and docs in there (which is only because it's my own project, so I've been lax there.

The next step for me is to integrate that nice django tagging module, as well as using epydoc to document my code and the doctest and unittest modules from the standard library to get proper code coverage.

The source can be found here

My wife and I have been reading a lot of graphic novels recently. One the graphic novels that we've been reading is Marvel's "Civil War" series. It's all about the U.S. passing a "Superhero Registration Act" which requires all superheroes to register their "secret identities" with the government. The superheros then naturally either choose to register or not, which results in a superhero civil war, with Iron Man fighting against Captain America. Hopefully you get the idea

Today I had a rather interesting conversation with a few "friends" of mine in the #django channel of irc.freenode.net about choosing between GPL and BSD. While this is a personal preference, my preference was the GPL, mostly because I have this feeling deep inside that it's almost morally wrong to modify an existing piece of free software and then sell it as a new product. Initially, it felt a lot like those graphic novels I've been reading, where each side is insisting they are "right" even though both sides were asserting that is was merely a preference. Eventually, we all came to an agreement that neither was necessarily superior to the other, but more of an answer to the question "What do I want to do with this?"

I've had conversations like this many times with other developers, sysadmins, managers, and the like. None of them has persuaded me as did those few other developers in #django tonight. I'm actually very seriously considering releasing all the source code to this site (which I will do in a few weeks anyway) under the BSD license instead of the GPL. Why? Well, I figure that the only people who would probably want to see my source code would be developers, not likely end-users (because nothing I've done is incredibly useful). Since it's more in the name of education, I don't really care what someone does with it. If they want to modify it and make money, be my guest.

While I'll continue to use Linux (GPLv2) instead of switching to *BSD, I feel like I had someone give me valid arguments for the BSD license, and like anyone who is willing to learn and grow, I'll accept and understand it.

I must say that I have never felt ripped off with an open source project. I don't even have to find myself amongst the dregs of the internet searching for a cracked version of whatever software. For the most part, when I try something new out, it's as easy as `apt-get install somethingnew` and I have it installed and everything (ah, the beauty of Debian). Free software is just that: Free!

This makes me then wonder why in the world others in the Linux/BSD community whine about X open source software or Y free software project. If GNU was powered by the principle of "You get what you pay for," we'd all be sitting in front of shiny new boxes, with the latest 3,598,271,345,687 core processor in it, and just staring. There'd be nothing there, because no one paid for it. Granted, sometimes you must have that eye rolling experience with some software, but I've learned as a developer you can either laugh or cry at those moments, and I much prefer laughing. So if you want a good project, pay for it. Just not with money.

Case in point: I've been trying to do a weekly release of new features for the site (which I have already deviated from on the first week I need to do something). Since this software is built on Django, the feature implementation has just been splendidly fun. But I've found one drawback: updates to models. If you want to change models around, add fields, remove fields, and the like, it's back to SQL for you. I'm comfortable with SQL, so that's not a problem. However, I like Django, and I like python. I want to stay where Django and python live, and play with them forever. Now, understanding that the fine details are NOT trivial, I've decided that I am going to fix the problem by creating a some sort of toolkit for resolving the dependencies, and generating a sql update script. This will make my life easier, and maybe, just maybe, someone else will benefit from it as well. I've been doing some proofing with hopes to have something out by the end of next week (to help with next weeks update).