01. Open Source

I just heard a Republican pundit on the radio talking about how Republicans are supposed to stand for individual efforts over taking care of others, and small government rather than large.

The Linux Link Tech Show (TLLTS) has a great segment dissecting the criticisms/wild flames put forth on a series of shows on the TWIT network. Wanted to add a couple comments missing from their discussion.

First of all, the Mac Break Weekly show apparently spends some time bashing the open source community, calling out Drupal, and how difficult it is to solve "simple" problems like uploading images for blog posts.

I started writing a response to a discussion in the latest "Linux Link Tech Show" episode, but ended up with something far too long, so I've split it up into 4 posts. The next post is about the TLLTS vs TWIT debate, and introduces this set of post.

In my early Linux system administration days, when I was first trying to set up a mail server with spam filtering, I ran across a really puzzling bug in Dspam, the software I was trying to get working. While all the other users of the software were getting great results, with Dspam catching 99%+ of all their spam, it was only catching about 70% of my spam after quite a bit of training.

I posted my results, and confusion, to the Dspam mailing list. The original developer of this software (which has thousands of users), Jonathan Zdziarski, responded that that did not sound right.

What's extraordinary about the open source community is that this level of support happens all the time, every day, without charge, in hundreds, thousands of projects out there. People that can get to the bottom of a problem and fix it at the source, not just provide a workaround, are directly reachable and motivated to see their software work as well as possible. They're not hidden away from the public behind a large corporation, unreachable with layers of clueless support script readers stuffed between you and them.

At Freelock, we're always trying to figure out ways to do things better. Recently I started digging into a developer tool that's making, as Bryan over at the Linux Action Show would say, my head explode.

For a long time, we've managed our custom code projects and business documents in a central repository, called Subversion (also known as svn). Subversion is relatively easy to understand--it's like having a library of files you can check a copy out of, do some work on it, and then check it back in. Subversion is the librarian that tracks who has copies of what, and when they checked it out. So if Erik checks in changes to a brochure, and then Jill goes to submit changes to the same document, Subversion will say "hey wait a minute, that document has already been changed--you need to make sure you put Erik's changes in your document before I'll let you put in your document."

This is great for managing conflicts between people working on a single team, or for code that is being developed in relative isolation from the rest of the world.

The problem is, we're doing more than that--we're taking code from various open source projects and either customizing it or building new applications on top of it. And so when the outside projects get updated, we need to manually update anything we've written that depends on that code. There is no longer a single repository where we control our code--there is our code library, plus another one for every project we use.

This makes managing add-ons for projects like Joomla or ZenCart quite challenging, because our add-ons get scattered throughout the filesystem to be able to hook into the right place. And if we have to touch a core file, we're going to end up needing to re-implement our change with any update to that core file.

There are other issues we run into, managing our code and hosting, all of which take fairly time-consuming, manual intervention. Here's the list:

• Since we host and provide security updates for Joomla, Word Press, Zen Cart, Drupal, and others, we need to upgrade dozens of installations any time there's a new release that has a fix for a security vulnerability. With Joomla this has happened quite a lot, and every Joomla installation needs to be upgraded individually--and tested. And since each installation is slightly different, we can't manage them easily within a single repository, while updating the underlying code.
• Templates, modules, components, blocks, themes, plugins, and whatever. Developing these types of add-ons are our bread-and-butter. But code for these often get scattered across an installation, making it quite difficult to manage just our add-ons while we develop them, or roll back to earlier versions if there's a problem.
• The Dojo Toolkit, and builds. We're doing a lot of development with Dojo right now, to add desktop-like functionality such as trees, sortable tables, right-click menus, animations, and lots of other really cool things. However, if you don't "build" the code after you write it, it's painfully slow in a web browser. And due to the nature of how Subversion works, you can't easily store a built Dojo tree if you ever want to change it again. Which means you'd need to build it every place you deploy it. And on some computers, it can take a long time to build--on our demo server, one of our projects currently takes 8 minutes.
• As we get more directly involved with open source projects like LedgerSMB, we're finding the need to change core files while we hack away at some particular feature. To do this, you create a branch of the code, work on your feature, and then merge your changes back into the "trunk." If you don't have access to save directly to the project repository, doing this gets a lot more complicated.

Git to the rescue. Git solves all of these issues. Read on for a technical discussion of how.

1. You want to make sure nobody will be able to read your documents in 10 years
2. You want to help your buddy who works for Microsoft have enough income to buy a private island in the Carribean, because maybe he would invite you to come for a weekend
3. You feel sorry for the PC on the Mac commercials
4. Your buddy is buying it for you from the Microsoft company store, so you're actually saving hundreds of dollars!
   

LugRadio has a very interesting discussion in their current podcast about the role of a community manager, in creating a vibrant community around an open source project. They came to the conclusion that each project needs a leader that people trust to take the project in the right direction, someone to be a diplomat to resolve issues among people in the community and keep everyone rowing in the same direction, and a strong technical lead to solve the hard problems.

This sounds quite similar to the challenges a small business faces.

A couple weeks ago, the EU slapped Microsoft with a $1.35B fine, less than a week after Microsoft had made a big fanfare about their new "open" policies.

Todd over at Napera asks,

Certainly the terms Microsoft has been offering companies since the EU decision in October 2007 are extremely reasonable. Given Microsoft’s new open protocol documentation and their patent pledge for open source developers, what’s not to like?

I haven’t seen any pundits or commentators in the US defending the EU decision.

Ok. Last post on the quality code series. One of the downsides of getting older is realizing you do have shortcomings. You know how when you're young, going into a job interview, the toughest question is the one about your weaknesses? We're all quite blind to our weaknesses, until experience comes up and forces you to realize you're not perfect. Sometimes this happens early, sometimes late, but it happens to everyone sometime.

My coding weakness, it turns out, is reliability. I'm terrible at handling errors, building test frameworks, doing unit testing.