Economic Musings

Just read a crazy article trying to inflame people to be against network neutrality. Study: Google uses 21X more bandwidth than it pays for. The study essentially states that Google pays a lot less for its bandwidth than regular Internet users, and uses much more of it. The implication of the story is that because of Net Neutrality, Google isn't paying its fair share of the costs of the Internet, and the poor ISPs just want to be able to make the biggest companies pay more.

Let's dissect this a bit.

Ok. Generally I avoid off-color language, but I've got yet another rant to get off my chest. And while it's mostly off-topic for this blog, I promise to connect the dots...

So there I was, walking the dogs home from work. I crossed the Fremont bridge, then down the block to the one major intersection I need to cross, just in time for the walk sign.

But there are cars stopped right in the middle of the crosswalk, underneath the red light.

For a time, "economies of scale" meant that the key to success was making a business bigger, and focusing on nothing more than profit. Sell more products however you could, and cut costs as much as possible. This is no longer the case. We're entering a time when smaller businesses that solve real problems can be profitable, and the former behemoths are becoming dinosaurs.

The past

The assembly line was the key innovation of the auto industry, that famous invention of Henry Ford.

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.

A friend of mine posted a story on Facebook that purports to explain income taxes, with beer. This led to a long discussion largely in support of its conservative message. I've found it on a few forums, purportedly by David R. Kamerschen, Ph.D. Professor of Economics University of Georgia. Here it is:

Our Tax System, Explained in Beer

Suppose that every day, ten men go out for beer and the bill for all ten comes to $100.

This week I'm at the Open Source Convention in Portland, aka OSCON. First impression, before showing up: it seems all focused on big business. Big ticket price. Lots of enterprise-related topics, and sponsors. Not really the meeting of geniuses and thought leaders as years past--or so I thought.

Second impression: Tim O'Reilly asking Brian Aker and Monty Widenius about the importance of various proprietary companies: Sun, Adobe, Microsoft. Their answer to Microsoft? Irrelevant. And Tim came back apologizing to the Microsoft sponsors.

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.

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.

I was listening to the latest episode of LugRadio the other day, and they had a discussion on vendor lock-in by open source distribution companies. I think they missed the point about vendor lock-in: that it locks users into a particular vendor, usually through some means that makes it hard to switch to a better solution later. So I wrote up a reply to send to them that I'm posting below, slightly edited.

I've spoken with a lot of entrepreneurs around Seattle, who have a misconception that using open source might somehow force them to give away their intellectual property. Intellectual Property is a hot topic around here, and entrepreneurs are told regularly how they need to have some to get funded. Yet they often think they can add their patented idea to free software and lock up their core idea. It's a bit funny how they want to have their cake and eat it too.

I'm talking specifically about patents here.