Don’t complain about it – make it better? Bug Jamming for a better tomorrow

Agreed, that was too much pathetic. But you got the point, didn’t you? Free software like every software is full of bugs and possibilities for enhancements. So is Ubuntu. But that’s okay, because we have the power to change it. No need to be a developer, no need to be an ubernerd. All you have to do is to spent some time. Need somebody to motivate you? Want to do it in a group? Then a Bug Jam is perfect for you!

No, it’s not a jam made of bugs :) It’s a get together where people work on eliminating software bugs by spending some time reading bug descriptions, checking them, writing new ones, informing developers about bugs or even patch the software by themselves. The Ubuntu community crew tries to push these events as they really help you to kick your ass and just get started as it’s much easier to get into the bug business in a group and it makes a lot of fun. And of course bugs fixed in Ubuntu can be ported to Debian and upstream quite often.

All you for a Bug Jam is… Ah, just come to one of the four Bug Jam irc sessions taking place in the next weeks, held by some Ubuntu people who already have some experiences with Bug Jamming and Ubuntu related events (I will support Daniel Holbach on two of them, one this Friday, 16:00 UTC). See the schedule on Daniel’s blog entry.

And keep in mind:

1. There is the 5-a-day project where you and your loco team, group or whatever can make a difference and pop up on the first line of the statistics.

2. There will be a Global Bug Jam which will be the first and biggest of it’s kind so far and you can be part of it.

Hope to see you there.


My 5 today: #156204 (pidgin-otr), #130443 (pidgin-otr), #144770 (pidgin-otr), #240420 (ubuntu), #231660 (ubuntu)
Do 5 a day – every day! https://wiki.ubuntu.com/5-A-Day

One step forward, two steps back – AOL’s new “openness”

Great news! AOL finally opens it’s OSCAR protocol for developers by providing extended information through its OpenAIM program with a SDK, tutorials and all you need to build up aim compatible messengers or even bots. But is it that open? I mean, we know the difference between “open” and “free”, don’t we? So a closer look at the license terms shows things you really don’t want to see and that are just unacceptable:

1. The “choose two from five” rule:


“Additional Feature Requirements. Any Custom Client or Web AIM Developer Application that you distribute must include at least two of the following features or functionalities (“Additional Features”) as an integral part of such distributed Developer Application:
  1. AIM Expressions. Inclusion of the capability for your users to choose and display a Buddy Icon to customize his or her user experience and provide a link to the AOL-Hosted AIM Expressions web page as documented in the AOL Additional Features document.
  2. AIM Toolbar. Inclusion of the AIM Toolbar as a user-selected option during the registration/download/installation process for the Developer Application, as applicable.
  3. AIM Start Page Launch. Inclusion of the launch of the AIM Start Page upon users. logon to your Site or to the Developer Application.
  4. Buddy Info. Inclusion of content provided by AOL that includes information about a user’s online status, including the user’s AIM profile, and AOL-supplied advertising.
  5. Advertisement. Inclusion of an AOL-provided display advertisement (“Advertisement”) within your Custom Client, Site or activity window. Unless otherwise provided in a written agreement, all revenue from such Advertisement will belong to AOL.”

source: http://dev.aol.com/aim/license

So let’s say you want to develop a free, non-commercial client. Your best choice’d be choosing to implement “AIM Expressions” and “Buddy Info”. That might be okay but it might be not. And actually it should be your decision, shouldn’t it? Even more interesting: What about console clients? Yes, they are around and it might be possible they haven’t ever heard of icons. Are they disallowed by default? Aren’t you free to choose a very different style of artwork for “expression” by dropping the standard set and developing a new one?

2. The additional “hope to be unsuccessful rule”

Okay, this might be pettifoggery, but let’s also assume your client is implemented with the mentioned
requirements, people start to download your client, so it is widely used. Fine? Uh, yes, AOL thinks so too, as they are really interested in that:

“In addition to, and not in lieu of, the above requirements, in the event that the number of simultaneous users of your Custom Client or Web AIM Developer Application reaches a peak level of 100,000 at any time (as defined by AOL and provided at http://developer.aim.com/manageKeys.jsp) you must either: (i) within ninety (90) calendar days also include an Advertisement within your Custom Client, on your Site or the primary activity window of your Open AIM Developer Application, and discontinue any version of the Custom Client or Site/Activity Window that does not include an Advertisement; or (ii) within fifteen (15) calendar days, contact AOL at the following address: aimcommercial@aim.com and reach agreement on alternative arrangements satisfactory to AOL.”
source: http://dev.aol.com/aim/license

So what is this about? If your application is a success, make it commercial in a way. Free software is for a niche, big market shares are for winners? Be afraid of having 100.000 peak users? Stop distributing uncommercial clients if having success?

So, really thank you, AOL, for moving towars openness. But the way you define “open” is not the way we mean it. It is not even “free beer” you are giving away, it’s a glass of free beer with a big refund sticker on it. But you already showed that you know what is all about: Just a couple of weeks ago information about a xmpp/jabber aol/aim test server leaked and you might have noticed how enthusiastic people were. Stick to it, be brave! Other big companies already use it by default.

Think about companies forcing developers to implement similar “features” into mail applications just because they transport mail to a specific domain, with a specific mime type or whatever. You would not like it? We don’t either. Make your protocol open and free. Your users are users – not customers, developers not employees.