Category Archives: OSL

Mozilla Trippin

Posted on by

Last week I took 3 days of vacation to make a trip down to the Mozilla office and work on a few projects. My trip went very well — it gave me time to focus and whiteboard things with Chase.

my desk

I spent the majority of my time working on AUS – which could stand for Automated Update Service or Application Update Service. I’m not entirely clear on which one it is, so let’s just say AUS. I was able to update the AUS Lite code to reflect our needs for branch updates.

In the previous version of AUS, branch testers would turn on their automatic update settings in Firefox or Thunderbird and then receive an update notification. The successive update would then upgrade their installation to the Aviary Trunk. Not good.

So the updated code now has awareness of the Version -> Branch relationship, which is a fancy way of saying that it knows which versions get what updates.

In the first run-through, AUS only knew about major updates for an entire product. This was to test the AUS client GUI in the beginning phases of the Deer Park feature, which is one of the major things that will be added to 1.5 applications (both Firefox and Thunderbird).

So now branch testers can stay on the branch, and everyone’s happy. Upcoming features for AUS would include a better build-system bootstrap, and a better way to generate XML output into static files (as opposed to being semi-dynamic). The upcoming feature list is relatively short, but it warranted some great discussion between Chase and I.

Needless to say, the future of Mozilla’s software update looks very bright indeed.

Other things I worked on:

  • Automated test scripts for AUS to verify correct output for pre-planned test cases that are stored in an .ini file. This ensures that new builds pass a sanity check, and would be ran from a web-interface or command line.
  • Bouncer updates, particularly with the user interface for the build system bootstrap via SUM file using Lars’ awesome loader.py script.
  • Some brief discussions with Rafael about the future of addons.mozilla.org (AMO).

Overall, I got a lot accomplished in the two days at the Mozilla office. Thanks to Chase and Karen for setting up this trip.

Unlimited snacks and redbull can make for a very productive geek.

Nerds are Regular People

Posted on by

Wake up, eat breakfast, ride the MAX. Convention buzz; free stuff, lights, displays, vendors and myriad sessions to attend. After-parties; free booze, free food, mingling. Sleep for a few hours. Repeat.

OSCON was something different for everyone. I’ve read through countless blogs about language wars, what’s hot or not, great epiphanies or laughing stocks. I didn’t find anything so life-altering that I feel the need to strap on my asshat and preach about this or that from my small little soapbox.

I will say that seeing everyone pulled together was very interesting. I couldn’t help but be amazed by the community — the people, not the booths. The faces and ideas were far brighter than the lamps in the exhibition hall.

Having never been to a conference like this before, I was pretty excited. I had never seen so many people with similar interests gathered in the same place. It was my first chance to meet a community I have known for so long but had never met in person.

After my first day, I asked myself what did I learn today? And most of what I learned had nothing to do with code but more to do with people:

  • Many of the people I met weren’t from the US
  • Almost everyone was very open and respectful
  • Nobody forgot to have fun
  • No dress code!
  • Even “famous” nerds were just regular people solving regular problems

Having been there, I now have this positive feeling of some sort of global/communal pride. The open source community is full of problem solvers. They find solutions to real-world problems everyday. They bang their heads on bugs, drink lots of caffeine, lose sleep over things and drink beer when they can. And the whole time they have fun doing it. Sounds a lot like what I do.

So I felt like I was a part of something. As corny as it sounds, that was the biggest impression OSCON made on me. We are the firefighters of the digital world, the construction workers of the IT industry, and the police of the internets. We all have our roles, we all contribute in some way, and every once in a while we come together at some convention like OSCON and celebrate it.

OSCON was a little like a family reunion. There were mothers, fathers, and the estranged cousin nobody likes.

The Pope and the Bazaar

Posted on by

Credit Eric Raymond for writing The Cathedral and the Bazaar, which is an excellent dive into the strengths and weaknesses of open source.

Like any written work, it comes with many interpretations. Raymond’s recommendations are awesome and should be recognized as lessons learned from the Linux software development model.

However, it’s no complete guide from point A to point B for your project. I think it would be a poor decision to take the Linux model and assume that your application should follow the same exact steps in order to be successful.

Yes, iterative improvements to a project codebase are a great idea. But when you’re trudging through piles of shit trying to decide whether or not to rewrite an application, you shouldn’t look at Raymond’s essay and believe, “If I fix this small piece, the rest will follow.” That sounds an awful lot like blind faith.

Invariably, at some point, a project hits significant crossroads; rewrites, branches, different languages. My take on Raymond’s essay was that each project endures these by drawing on sound judgment from its leaders. Of course, in the essay that means Linus and Eric. As Raymond laid out, each iterative improvement was never a miracle or sponateously generated.

Eric chose his starting point for his mail client project. He changed it, destroyed it, rewrote it. Linus chose his starting point and went through many of the same challenges.

Each improvement was borne from a specific need that was unfulfilled for a member of the community. The leader of each project was able to effectively manage their primary resource (their user base) in order to facilitate an organized effort to scratch any collective itch. This is what made all bugs shallow, given enough eyes.

Mozilla office.
The common thread that struck me was the presence of a central body in both cases. For all the clamour and praise for a distributed development model that uses the force of the community, it still seems as though any effort would die without organization and leadership. At some point hard decisions are made — like, “Should we rewrite this entire thing?”

In his epilogue, Raymond touches on the unknown nature of open source in general. Yes, it is sometimes a tremendous success story, one of the best, probably better than watching Rudy play garbage time in the fourth quarter. But I fear people forget about the pitfalls and weaknesses of open source.

Remember, for all of open source’s grandeur, it’s still just a part of the natural ebb and flow of a necessity-driven sea of developers. It’s evolution, in all of its greatness and all of the horrible wreckage it leaves behind.

The process of finding that leader, that epicenter of motivation and organization is a part of digital darwinism. Sometimes projects find it, the leaders match the community well, and progress is made. Other times, more often than not, a project can stagnate and spiral towards extinction.

So what did I learn? Know your needs — understand them. When your application doesn’t meet them it’s time to tear things down and write one that does; piece by piece or all at once — doesn’t matter. Don’t worry about what happened to project X; do what’s right for your project and its users.

Be willing to fail, and fail hard. Be willing to build things up, burn it all down, and rebuild it. Do it again. Include as many people as possible, ride the wave but scratch all of your itches. Then finally – succeed together, quietly, but don’t be surprised.

It’s not just software evolution.