Notes In The Margin

I had something of an epiphany in the shower this morning. I discovered that I actually agreed with Bradley Kuhn about something.

TLDR: Is "the cloud" a threat to Open Source? I stopped working on an Open Source calendaring project because of Google Calendars.

Several months ago I attended (part of) a talk by Bradley about how The Cloud (whatever that is) is a threat to Free Software. (Yes, I know what The Cloud is. Snarky remark in reference to all the different things The Cloud might mean to various people. See Simon Wardley's wonderful talk about what the cloud is.)

His reasons struck me as so outside of my way of thinking about software that I ended up leaving the talk. Oh, also, Skippy wanted to go to lunch, and that sounded like a lot more fun. Nothing personal, Bradley. He was talking about how something like Google Calendar (actually his example was GMail, but hold on a minute) was a threat to Free Software because the code, even though it's in Javascript and right there in front of you, can't really be inspected (ie, you can't learn from it) because it's hugely obfuscated. Also, you can't see the back end. So here's a service you can use for "free", but it's not Free, because it's in chains, metaphorically speaking.

Then, this morning, I was thinking about why people are involved in Free/Open Source software, but also why they stop being involved, and I realized something.

I used to have a web-based calendar thingy. It was written in Perl, and it was really very cool. In fact, it not only started my passion for Open Source (it was the first thing I ever had on CPAN, and it was the first software that I ever wrote which was featured in a book!) it also paid my mortgage for a few years. I used to write calendaring applications for the General Motors Desert Proving Grounds in Mesa, Arizona. Although that plant is long closed, their scheduling ran on my software. If you wanted to schedule a test on the dust track (tests a vehicles various rubber seals to make sure they keep out dust, as well as handling in those conditions) you used the web-based scheduling application, called D.U.S.T. (I forget what it stands for - Dusttrack Usage Scheduling Tool or something) and scheduled it. This worked better than grubby bits of paper, because it didn't get lost, and you always could get to it without walking down the hallway.

Also, when I was at Databeam, back in the late 90s, I wrote a similar application for scheduling conference rooms (clever name: Conference Rooms). I went up to the front desk one day and stole the conference room scheduling book and hid it, forcing everyone to use the online scheduling app. Strangely, it worked, and I didn't get fired.

Then, I got involved in a project called Reefknot, which was an implementation of various international calendaring standards, in Perl. That was humming along nicely. And I had a dozen different calendar modules on CPAN.

By the way, in case you don't know, calendaring is hard. Sure, it looks easy, but then you get into things like "every other Monday at 10am, except during company vacations." Or possibly "the last day of each month." Think for a little while about how you'd implement that, and your brain will start to melt just a little. "every monday" suggests a simple solution, but as soon as you start having to deal with exceptions, things get very very complicated. And what with different length months and leap years ... and don't even get me started on time zones. *shudder*

Anyways, then something called Google Calendar came along. It worked with all of the various calendaring applications. It did the various calendaring specifications, including the long-elusive CalDav. We were all very excited in the calendaring community, but then an odd thing happened. People stopped working on calendaring stuff. Because, you know, it's already done.

So, I stopped working on an Open Source project because there was an implementation in the cloud. (ie, online somewhere.)

So, was Bradley right? Did Google Calendar kill the Reefknot project specifically because it's closed source? Yes, in a sense. I don't believe, as the FSF does, that closed source is intrinsically immoral. But there's a direct correlation between the projects I no longer work on, and great cloud based implementations of the same functionality, where I don't have access to the source to participate.

Furthermore, as my interaction with software is increasingly via a browser, and not via running software on my own computer, I have less and less incentive - and ability - to tinker with those things.

Now, I'm weird, I still run several of my own servers. Granted, those servers are "in the cloud", meaning that I have no idea where they are physically located. But I have root on them. I build software from source on them, and tinker with that source from time to time. I tinker with the source code of my blog, even though there's a good blogging platform "in the cloud", but I also have several blogs on Blogger, simply because it's simple and I don't want to monkey with it.

So, although I disagree with Bradley's philosophically, I find that he may be completely right for more pragmatic reasons.

But at the same time, Open Source has a whole new rebirth of late, and there continue to be ever more exciting projects out there. I'm much more concerned about my kids, and what they will find to hack on. My son is a hacker. He likes to build stuff, take stuff apart, break it and fix it, figure out how it works. I don't know if I'm doing an adequate job of encouraging this. I really need to get him a subscription to Make magazine. I wonder, however, when he gets a little older, if he'll be interested in programming. I think he'd be really good at it, but it would be a great shame if the removal of applications to The Cloud also results in a lack of opportunities to hack on code.

I just got done reading "Squid Proxy Server 3.1 Beginner's Guide" by Kulbir Saini, from Packt Publishing.

(Full disclosure: Packt sends me free books on the condition that I review them. However, I'm under no obligation to say nice things, and they keep sending me books even when I say harsh things.)

Quick version: The writing style is ideal for a beginner - clear descriptions of concepts, rich in step-by-step examples and section reviews/summaries to clarify why you just did what you did. Frequent exercises reinforce concepts. Saini writes like a teacher.

Saini's writing style suggests to me that he's been teaching this material for quite some time. Every concept has copious examples and suggested exercises to help you remember what you've learned. Concepts are clearly defined, clearly explained, and then illustrated before moving on to another concept. Previous concepts are reintroduced and incorporated into the new ones as you go along, so that idea builds upon idea.

This is a book to be read in order, but aso is structured so that someone at an intermediate level can go back and use individual sections as reference.

I love reading technical books that aren't dry and boring, and which inspire me to be a better writer. Oh, yes, and I learned a lot about Squid, too.

I presume that the content isn't really quite so specific that it's only for 3.1, but having not used Squid for an extended time, I can't say for sure.

The book starts with clear descriptions of the general concepts of proxying, but very quickly gets hands-on and specific to Squid. This is how I like it, because I learn by examples and doing.

So, on the whole, I give this book a firm thumbs up. I'm always a little hesitant doing a review of a book on a technology I don't know by an author I don't know, because I make it a firm rule to say the book stinks if it stinks. So it's always a joy to read a book like this that exceeds my expectations, and turns out to be not just ok, but actually really well written.

A quick reminder that Tek11 is just a week away, but there's still time to get your tickets. I'll be speaking twice - once about all of the things you didn't know the Apache HTTP Server could do, and once about writing a better FM. And, of course, dozens of far-more-brilliant people will be there too, speaking about many PHP-related topics, and hanging out having fascinating conversations, and working on fascinating projects.

You can hardly afford to miss it. See you there.

Tek11 is just a month away, and you should come. PHPTek is one of the best conferences I attend, always full of practical, usable presentations. It's primarily a PHP conference, but also has a great deal of web-related content and awesome people to hang out with.

This year, I'll be giving two talks.

The first, N Things You Didn't Know Apache Could Do is a high-speed sprint through N features of Apache HTTP Server (N is currently 25, I think) that, in my experience, most folks are unaware of. And, with the release of 2.4 imminent, much of this content will be focused on the cool new stuff in 2.4.

My second talk, Write A Better FM, is completely new content for me, and is about what it takes to make your documentation and your customer support more customer-focused, and less ... ahem ... traditional, free software, the luser is an idiot and an annoyance, RTFM style. This draws on my 15 or so years of working in Open Source documentation, in the Perl, Apache, and PHP communities, as well as writing a half-dozen books.

In addition to these two talks, there will be many community luminaries giving a wide range of talks which, if the last 4 years are any measure, you'll be able to go back to the office and apply immediately.

You should come.

Having discovered that Chrome has pinnable "app" tabs, too, I've moved back to Chrome, for three reasons.

1) It's WAAAAAY faster

2) Typing stuff in the address bar consistently loads Google search results for that stuff, whereas Firefox does sometimes, and other times it'll load whatever site it deems the best match. While I'm sure that's configurable, I'd rather not have to hunt for it.

3) The thumbnails of my most frequent sites is really quite useful. There's a plugin to do this for Firefox, but it doesn't actually do this - you have to manually add each site.

These are all pretty minor things, and of course I'll still have to use Firefox while developing.