A backgrounder on the free software movement

Understand, first of all, that the free software movement aims not to abolish the sale of software, but to to protect a person’s freedom to use, inspect, modify, and share software. As they say: free, as in speech, not free, as in beer. In order for a piece of software to conform to the free software foundation’s definition of free, its license must grant users of the software the following four freedoms:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

Source: “The Free Software Definition”

The GNU GPL goes one step further to say that any time you redistribute software that is derivative or comprehensive of free software, your software must be redistributed under a GPL-compatible license. It is this share-alike provision and its implication for software based on interpreted programming languages like Javascript, whose usefulness is only truly realized when the source code is distributed over a network and executed on a client computer, that forms the subject of this essay.

When use means use, and distribution means distribution

The share-alike provision of the GNU GPL is designed to prevent middlemen from stripping away any of the four freedoms from free software, on its way to the end user. To be clear, a person is free to build a piece of software atop someone else’s GPL code, and to use that software to conduct business activity for profit; this would constitute the exercising of freedoms 0 and 1 – the freedom to run a program, for any purpose, and the freedom to adapt it to their needs. To subsequently exercise freedoms 2 and 3 is purely optional, but if the user chose to exercise their freedom to distribute copies of their modified software, and distributed those copies under a license that restricts any of the four freedoms that they themselves were treated to, they would be in violation of the GNU GPL‘s share-alike provision.

When use and distribution go hand in hand

Considering the scenario I’ve just mentioned, what if the software in question is written in an interpreted language like Javascript, and built atop GNU GPL licensed Javascript code? Further, what if the person’s business is the provision of a web application – a type of application which, by virtue of its architecture, requires that Javascript source code travel over-the-wire to be executed on the client side, in order for the web application to be usable? Is the business owner exercising freedom 0, to run free software for any purpose, or do we say that she has exercised freedom 3, to distribute a modified copy of the software – her modifications now being subject to the share-alike provision of the GNU GPL?

Intent only to use

One might say that the business owner’s intent was to exercise freedoms 0 and 1 exclusively. The business owner may think of herself as the sole end user of the Javascript software – software that they use to provide a service to their customers over the Internet. Said service might be a dating service, or perhaps a service for ordering pizza delivery.

De facto, though, the distribution is

Whatever the business owner’s intent, the fact is that the architecture of a Javascript-based web application requires Javascript source code to be distributed over-the-wire in order for it to be useful; de facto distribution of Javascript source code occurs every time a web application is accessed. The users of the business’ service are, in fact, the end users of the business’ modified version of the original, free program.

Freedom isn’t free

Chances are that one of those arguments will have seen readers get a little hot under the collar, so let’s relax for a moment. By now we all understand the principles of free software, and our business owner surely wants to uphold the agreement that she entered into when she chose to build her software atop GNU GPL code. We’re all essentially on the same side, but because of the nature of the web, we find that we’ve been stripped of our agency to decide when to exercise our freedom to use free software, and when to exercise our freedom to distribute it. The two have become inseparable; client side Javascript is only usable when distributed.

There exist some edge cases where Javascript code need not be distributed to be useful. You could wrap it in an Adobe AIR or Silverlight application for your own personal use. You could use Rhino to embed it in a Java application for your own personal use. You could even build an application that runs in a browser, but only ever load it locally. These examples are specious, though. However plausible, the choice to use Javascript in these instances would likely not be the best available one.

For the remaining, typical, client-server, web-centric uses of Javascript, it would seem to me that there exists no opportunity for the creator of a derivative work based on GNU GPL Javascript code to derive value from their program without being forced to exercise freedom 3 by virtue of the consequential distribution of Javascript source code. Proponents of free software call Javascript a trap. I sense that “trapped” is how most of us feel about the deadlock between the Javascript community and the free software movement.

Repercussions and implications

The licenses of the free software foundation have found themselves the target of a number of Javascript developers’ ire. When Jack Slocum’s ExtJS project relicensed their Javascript library under the GNU GPL, their community fractured (of interest is this conversation between Jack Slocum and jQuery’s John Resig). Google around and you will find Javascript developers blogging the GNU GPL as “sneaky,” or “a virus.” This is likely a consequence of people failing to recognize that the explicit aim of the GNU GPL is not to sneakily restrict the freedoms of developers, but to guarantee the freedoms of users, of whom developers (don’t forget) are a subset. Put another way, copyleft, share-alike licenses like the GNU GPL concern themselves with user freedoms, while more permissive, BSD style licenses concern themselves with developer freedoms. Since BSD style licenses permit the total appropriation of free software by middlemen, and the GNU GPL doesn’t, one might argue that GNU GPL licensed projects are more sustainable. However true elsewhere, this has not proven to be the case with Javascript libraries.

Perhaps the decision facing the Javascript developer who wants to build software atop GNU GPL Javascript code involves choosing the lesser of two evils.

Consider the case of the pizza parlor, who uses a web application based on GNU GPL Javascript, with custom modifications, to improve the efficiency with which they can deliver their service, namely: tasty pizza to your door in 30 minutes or less. If the employees of the pizza parlor used the web application to process the order of someone who called in over the telephone, there would be no problem – the parlor is exercising their freedom to run the program without distributing it. The moment they cut out the telephone, and expose that web application to the public so that customers can key in their own orders, de facto distribution has occurred, and the pizza parlor’s modifications are subject to the share-alike provision of the GNU GPL.

That being the case, it’s not clear that this is anything to fear. If the core business of the pizza parlor is the delivery of tasty pizza, and not the provision of software to manage a pizza parlor, should they be afraid of sharing their modifications? If the user’s core business is something other than the provision of software, it’s likely that their software modifications are trivial, or at least peripheral to their core competency – an animation class that makes a wedge of pizza fly across the screen, or a validation class that validates form input on the client side. In this case, the lesser evil may be to embrace the conditions that force her to share-alike, in exchange for the benefits the business owner enjoyed by having access to the GNU GPL Javascript upon which she based her application in the first place.

On the other hand, if your business actually is the provision of an online pizza parlor management service, then you’re probably in the business of providing software as a service, and ultimately, because of the nature of the web, the business of distributing software; a move that will reliably trigger the share-alike provision of the GNU GPL. In this form, we find that the GNU GPL functions as intended: to discourage the incorporation of free Javascript software into proprietary Javascript software, of which software as a service is a part. No surprises there.

A world where all users are free, except those who happen to be less free than the rest

A creator of a web application which incorporates client-side GNU GPL Javascript code may think of themselves as the end user of that web application, but they’re not; the architecture of the network forces them to distribute their modified Javascript source code in order for their application to deliver value to them. Though circumstance alone triggers the share-alike provision, it’s probably also the case that the creator should not fear having to share their client-side code, since their competitive advantage should come from the work they do in the back office (or, in the case of the pizza parlor, the kitchen).

If distribution, as a precondition of use, is going to trigger the share-alike provision for all web-delivered Javascript software, then so be it. There’s something unsatisfying, though, about knowing that all users of free software are free to exercise their freedom to adapt free software, and to run that software for any purpose, without being required to exercise their freedom to distribute their modified version… except if the purpose requires that it execute on a remote, client runtime.

But after all, it’s about being free, as in speech, not free, as in a decaf grande half-soy, half-low fat, iced vanilla, double-shot, gingerbread cappuccino, extra dry, light ice, with one Sweet-n’-Low and one NutraSweet.

Opening the door to VLC’s secret telnet interface

Alright, it’s not so secret. For my purposes, though, it was rather poorly documented.

Enabling VLC's Telnet Interface on Mac

First thing to do, is to launch VLC, and choose (VLC > Add Interface > Telnet Interface) from the menu bar. For non-Mac users, I believe this option lives under the “Settings” menu.

Don’t quit VLC at this point! You will need to keep it running from now until the end of your scheduled recording. Also, make sure that your computer is not set to sleep after a period of idle time, and that your housemates know not to shut the computer down or put it to sleep.

Connecting to VLC through telnet

VLC opens a telnet interface at port 4212 of your local machine. Mac users can launch the Terminal application (typically found in the “Utilities” subfolder of your “Applications” folder) to make a connection.

Open Terminal and type the following:

$ telnet localhost 4212

The password, by default, is admin.

Trying ::1...
Connected to localhost.
Escape character is '^]'.
Password:
Welcome, Master
>

Once you’re in, you can start issuing commands directly to the VLC client.

Defining a broadcast

The “magic incantation” to define a broadcast, and the file to which you would like it saved, is as follows:

> new {name_of_broadcast} broadcast enabled input {url_of_broadcast} output #std{access=file,mux=raw,dst={path_to_which_to_save_broadcast}}

Phew! In my case, where the broadcast I wanted to save streams from http://live.citr.ca:8000/stream.mp3, and I wanted VLC to save the recording to my Desktop folder, the incantation went as follows:

> new citr_radio broadcast enabled input http://live.citr.ca:8000/stream.mp3 output #std{access=file,mux=raw,dst=/Users/sluscher/Desktop/lakefield_show_stream.mp3}

I called my broadcast citr_radio, but you can call yours whatever you like. Also, make sure that the path to your destination file exists.

Testing, testing – 1-2-3

At this point, the recording is ready for scheduling, but before we do that, let’s make sure that we spoke the magic words correctly. Here, we’ll use the control directive to test out our broadcast recorder. Incant the following:

> control citr_radio play

A file should appear at your destination path, and VLC should be dumping your broadcast into it. Let the tape roll for a few seconds, and then type this to stop it:

> control citr_radio stop

If all went well (and VLC doesn’t report any errors when you bring it to the foreground) then you should be able to open the file that was created with VLC and listen to what you’ve recorded!

Scheduling the recording

Once you’ve demonstrated that you can manually start and stop the recording, it’s time to schedule a recording. The scheduling syntax looks like so:

> new {name_of_schedule} schedule enabled date YYYY/MM/DD-HH:MM:SS append {command_to_run}

The time is in 24 hour clock, based on your system clock, and name_of_schedule can be anything you like. In my case, I wanted to schedule a start and a stop coincident with my band’s performance on the radio:

> new lakefield_show_start schedule enabled date 2009/03/19-21:00:00 append control citr_radio play
> new lakefield_show_end schedule enabled date 2009/03/19-23:00:30 append control citr_radio stop

Once you’ve set the trap, you can conclude your telnet conversation with VLC by typing:

> exit

Feel free to quit Terminal at this point, but leave VLC (and your computer) running until the end of the broadcast.

That’s that!

Here’s the whole magic spell:

$ telnet localhost 4212
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Password: [the password is "admin"]
Welcome, Master
> new citr_radio broadcast enabled input http://live.citr.ca:8000/stream.mp3 output #std{access=file,mux=raw,dst=/Users/sluscher/Desktop/lakefield_show_stream.mp3}
> new lakefield_show_start schedule enabled date 2009/03/19-21:00:00 append control citr_radio play
> new lakefield_show_end schedule enabled date 2009/03/19-23:00:30 append control citr_radio stop
> exit
Connection closed by foreign host.
$

…and for your listening pleasure, here is Lakefield on CiTR’s Thunderbird Radio Hell!

Let’s say that you’ve ended up with a time like March 8 2009 03:00 UTC, where you meant to say PDT instead of UTC. Wouldn’t it be nice to be able to change only the zone part of the time, without changing the local representation, like so:

>> t = Time.zone.parse('March 8 3am')
=> Sun, 08 Mar 2009 03:00:00 UTC +00:00
>> t.zone = 'America/Los_Angeles'
=> "America/Los_Angeles"
 
>> t                            # It's 3:00am in Vancouver!
=> Sun, 08 Mar 2009 03:00:00 PDT -07:00
>> t.zone = 'America/Denver'; t # It's 3:00am in Edmonton!
=> Sun, 08 Mar 2009 03:00:00 MDT -06:00
>> t.zone = 'Saskatchewan'; t   # It's 3:00am everywhere!
=> Sun, 08 Mar 2009 03:00:00 CST -06:00

You can, if you add this method to ActiveSupport::TimeWithZone:

module ActiveSupport
  class TimeWithZone
    def zone=(new_zone = ::Time.zone)
      # Reinitialize with the new zone and the local time
      initialize(nil, ::Time.__send__(:get_zone, new_zone), time)
    end
  end
end

In my application, my users set start and end times for their events. I was able to make use of this new zone= method when they choose a new time zone for their event; it lets me preserve the local representation of the existing start and end times between time zone changes.

It’s true that you can write your own range conversions and add them to ::Range::RANGE_FORMATS. Those conversions could refer to translations in your locale bank, but I’d prefer to see what the range formatter is doing without having to look in two places. I wanted a formatter that would do something like this, where :fancy can represent a different Proc depending on the current locale:

>> (Time.current..Time.current+1.hour).to_s :fancy
=> "Monday, February 16th, 2009 between 6:00pm and 7:00pm PST"

First, I implemented a version of Range#to_formatted_s that’s I18n aware (thanks clemens!).

config/initializers/range_conversions.rb:

# Allows you to do things like (Time.current..Time.current+1.day).to_s :local_format
# where range.format.local_format is an entry in one of your locale files
::Range.class_eval do
  def to_formatted_s(format = :default)
    formats = ::Range::RANGE_FORMATS
    formatter = formats[format]
 
    unless formatter
      formatters = I18n.translate(:'range.formats', :raise => true) rescue {}
      formatter  = formatters[format]
    end
 
    formatter.respond_to?(:call) ? formatter.call(self.begin, self.end) : to_default_s
  end
  alias_method :to_s, :to_formatted_s
end

Next, I edited my locale file:

config/locales/en.rb:

{ :en => {
 
  # Range
  :range => {
    :formats => {
      :fancy => lambda { |start_time, finish_time|
        start_format = "%B #{start_time.day.ordinalize}, %Y between %l:%M%p"
        finish_format = "%l:%M%p %Z"
 
         "#{I18n.localize(start_time, :format => start_format)} and #{I18n.localize(finish_time, :format => finish_format)}"
      }
    }
  }
 
} }

And there you have it; fancy-formatted date ranges with localization.

I use RSpec and Cucumber, and wanted rake:notes to traverse my spec and features directories. To achieve this, I created a file called lib/tasks/notes.rake:

# Override the directories that the
# SourceAnnotationExtractor traverses
# when you call rake notes
class SourceAnnotationExtractor
  def find_with_custom_directories
    find_without_custom_directories(%w(app lib spec features))
  end
  alias_method_chain :find, :custom_directories
end

The scenario

I was working on a live search plugin for WordPress; one that displays matching results below the search box as you type. The PHP part of the plugin was designed to hook into WordPress’ search facility and make it output JSON, for the Javascript part of the plugin to consume and display. The hook was designed to run only if a search was initiated by an AJAX request. To detect such a request, and implement the context switch, it made use of the “X-Requested-With” header sent by the MooTools framework:

function json_requested() {
  return  isset($_SERVER['HTTP_X_REQUESTED_WITH']) &&
          $_SERVER['HTTP_X_REQUESTED_WITH']  == 'XMLHttpRequest' &&
 
          isset($_SERVER['HTTP_ACCEPT']) &&
          $_SERVER['HTTP_ACCEPT'] == 'application/json';
}
 
if($this->json_requested()) {
  // Output the query as JSON
  add_action('wp', array($this, 'output_search_results_as_json'));
}

The bug

An unexpected response received upon revisiting the search results page using the back button.

This worked quite well, but my client began to notice an intermittent bug. On occasion, when making a non-AJAX request for the search results page, then leaving the search results page by following a link, then clicking the browser’s back button to return, the browser would display (Internet Explorer 6) or begin to download (Firefox 3) the JSON version of the search results, instead of the expected HTML response. When I heard the word “intermittent,” I smelled a race condition, opened up my trusty Charles web debugging proxy, and set to work trying to recreate the error.

The problem

What I found was that the last response to return for a given URL would be the one that the browser would cache, no matter what kind of response you were expecting given a certain set of request headers.

Here is what Charles says about the order of server responses with the bug absent. You’re looking at a set of four AJAX requests initiated by the Javascript application, and responded to by the server, followed by a non-AJAX request initiated when the user clicked submit on the search form. 

Last response to arrive is the HTML one.

Next, what we have is Charles’ report at the time the bug was discovered. Three AJAX requests receive responses, and while a fourth one is in progress, the user submits the search form. As we can see, the fourth JSON request returns after the HTML search page returns. The last response across the finish line, is the one that the browser will remember for the URL /?s=food.

Last response to arrive is the JSON one.

Solutions

Turns out, you have at least two simple solutions in this case:

1. Cancel all of the AJAX requests at the time the form is submitted
2. Use a different URL according to the response you expect

In my case, I opted to make use of the cancel() method on my instance of the MooTools Request class to ensure that any AJAX requests for JSON would be killed before a request for the HTML version of the search results page even got rolling.

steveluscher.com from 2001–2008

It’s unclear what finally pushed me into the blogosphere. I’m not sure that I can point to any one trigger; it’s more likely the work of a lifetime of backburnered  thoughts, unsung opinions, and dusty ideas that led me to hollow out this piece of the internet, erect an .htaccess file, and call it my own.

I’m starting with only a handful of goals. I intend to spend hours, not seconds, crafting publishable material, so that would-be readers receive carefully considered prose more often than verbal diarrhea. Also, being a designer, I would like each and every post I publish to be accompanied by at least one editorial photograph; if it’s not worth illustrating, it’s not worth publishing. As for how to categorize and tag posts, and what sort of navigation to make available to visitors… I’ll work that out as I go.

The Aggregator

The one navigational device that I’ve provided off the bat, other than tags and topics, is something that I call “The Aggregator.” Each time I publish a post, I will describe, in one short sentence, what I think that post says about me. The Aggregator will pull these sentences at random and display them as links to the posts they belong to.

Being late to the game, I’ve ported some of my old writing to this blog to fatten it up for launch. Here’s to all of the words I have yet to write.

The bell rings:

Let’s frame the discussion; A client hires you to build a web application, they bring a wish list of things they want it to do, and they ask you how much it’s going to cost. The more you know about what’s required, the more accurate your estimates will be, so you begin to size up the scope of the work by putting the project’s requirements down in writing. You can gather and store those requirements in a ticketing system like Lighthouse or Jira, but you can be similarly effective using Post-it notes and a smooth wall. Let’s bracket out the discussion about tooling, assume that we’re going to use the term “ticket” to describe a distilled requirement, and take a look at the component parts that make up a requirement:

1. Ticket title
2. Ticket description
3. Ticket milestone

1 – Ticket title

The title of a ticket should strike to the very heart of the requirement, summarizing it succinctly and unequivocally. As is true of great ticket content, a great ticket title should be:

1. Testable – you’ve made an assertion about what outcome you desire
2. Contextual – you’ve described the conditions and nature of the players involved
3. Granular – you can’t break this requirement into smaller requirements

The pro requirement gatherers that I’ve come to know develop formulas for their ticket titles, and stick to them. If this was your formula:

{persona} should {imperative} when {condition}

…you might expect to see the following ticket titles:

The system should present visitors with a newsletter
subscription form when the signup link is clicked
 
The system should present an error message when
a visitor submits a subscription form with errors
 
A visitor should be added to the mailing list
upon signing up for the newsletter
 
A visitor should be presented with a confirmation
message upon signing up for the newsletter
 
The system should send monthly subscription
reminders to those on the mailing list
 
An administrator should be able to send
a plain text email to mailing list subscribers
 
An administrator should be able to send
an HTML email to mailing list subscribers
 
The system should remove a subscriber from the
mailing list when their emails are found to bounce
 
A subscriber should be removed from the mailing list
when they click the “unsubscribe” link
 
A subscriber should be presented with a confirmation
that they've been unsubscribed when they click the
“unsubscribe” link

Things to notice:

1. Each ticket title describes a discrete user/system interaction. Note the splitting of plain text and HTML emails into two separate tickets. From a systems perspective, they may involve two very different pieces of code and, as such, constitute two requirements.
2. The development/design activity represented by each ticket can be tested for completeness by title alone, by asking the question “did the {persona} {imperative} when {condition}?”
3. As I wrote the ticket titles, a set of personas emerged; they are: “the system,” “a visitor,” “a subscriber,” and “an administrator.” Like good characters in a book, these personas will develop as the story unfolds, and should follow you around for the entire duration of the project.

If your instincts told you to bundle all of those tickets into one ticket called “Newsletter,” you may have a medical condition called “epiccitis” – a propensity to write Epic Stories. Epics are a great way to bury complexity where it can’t be seen, leading to underestimation, and ensuring that your projects will run over time and blow your budgets. Write Epic fiction, not Epic Requirements.

2 – Ticket description

If your ticket description is half as good as your title, you’re still well on your way. Let’s extend the system that we used to write our titles, and write example ticket content for the ticket titled “The system should present visitors with a newsletter subscription form when the signup link is clicked.”

TICKET TITLE:
The system should present visitors with a newsletter
subscription form when the signup link is clicked
 
TICKET DESCRIPTION:
Upon clicking on the “subscribe now” button,
a user should be required to supply
the following information:
 
  * Name
  * Email (validate against RFC 2822)
  * Acceptance of privacy policy
 
…and may optionally provide:
 
  * Occupation
  * Telephone number

Now there’s a requirement that designers and developers alike can sink their teeth into, right away!

3 – Ticket milestone

I’ll tell you how I feel about this, then you can develop a system that works for you.

Milestones should occur regularly, like a heartbeat. For simple projects, set a milestone every week. For complicated ones, three or four weeks.

Milestones should never move; the only thing that should move are requirements – in and out of milestones. When surprises come up, write the surprises down as new requirements (new tickets) and do one of three things:

1. Schedule the new requirements in a future milestone
2. Move requirements out of the current milestone and into a future milestone, to make room for the new ones
3. Add the new requirements to the current milestone and assign additional personnel to that milestone; the more people working on a milestone, the more requirements it can hold

When a milestone is reached, a snapshot of the project should be deployed, unfinished tickets (tsk, tsk) should be carried forward, and beer should be un-fridged.

Therefore, good milestone names:

Iteration 1
Iteration 2
Iteration 3 (Internal Launch)
Iteration 4
Iteration 5 (Public Launch)
Iteration 6

Bad milestone names:

After Friday
Whenever you get time
Yesterday

School’s out

If writing requirements in this way seems overly complicated and time-consuming, there’s good news: you can reuse them. The first time you write a series of stories for “new user registration” it will seem like time is standing still, yes, but if you write them in an abstract way, you should be able to drop them into all subsequent projects that require “new user registrations” and customize them from there.

Oh… I almost forgot; here are the answers to the test:

  great requirements
= testable requirements
= clarity
= accurate estimates
= less rework
= more met deadlines
= happier clients
= happier staff
= ???
= profit!

So next time you sit down to write a ticket, if you can’t think of a good title, chances are you don’t really know what’s required. And, as we’ve learned from G.I. JOE, knowing is half the battle.

Step 1:
Want to order something from a US retailer, likely because it’s being sold for less than the cheapest Canadian retailer will sell it for, or because it’s just plum not available above the 49th parallel.

Step 2:
Notice that said US retailer either won’t ship internationally, charges damn near the original value of the item for shipping to Canada, or offers really attractive free shipping to US addresses. Now is the time to pound your fist against the desk, swear, or grumble something about living in a country that’s understood only as the land of “igloos” and “eskimos.”

Step 3:
Calm down. Click that “checkout” button. When it comes time to put in your shipping address, try this little number:

{Your Name Here}
1591 McKenzie Way
Point Roberts, WA
98281

Step 4:
Register yourself with Point To Point parcel, so they know to notify you when your package arrives.

Step 5:
You’ve received notification that your parcel has landed in Point Roberts! Grab your passport, a knapsack, your bike and get on the 601 bus. Take it all the way to the end of the line (52A street and 2nd), ride through Diefenbaker park, and locate the big orange square in the sky. That’s the border crossing.

Step 6:
Visit your good friends at Point To Point parcel, show your ID, and grab your goods!

Step 7: Ride back across the border and pay your taxes. Y’know, the ones that paid for the bus ride down?

There you have it! Enjoy near-free shipping, competitive prices, a whole new world of selection, and good exercise. It’s the Point Roberts difference.

Other Point Roberts depots include TSB Shipping and The Letter Carrier. These instructions are intended as guidelines only – always plan ahead, read the depot’s terms and conditions, check the latest transit schedules, and make sure that you understand the implications of cross-border travel and trade.

None of the above. I’m a sustainable transportation advocate!

I’m not sure how I escaped the gravitational pull of suburban cartown, with all of its union-wage factory jobs, cheap suburban homes, and open roads. Maybe it had to do with the world-view I inherited from my first-generation European parents that inspired me to pursue the arts, world-travel, and a University education instead. Enough about me though; this article is about the countless among us in love with – nay, addicted to – the automobile.

To help you understand where car-love comes from let me take you on a trip, back to my own childhood in suburban Oshawa. Picture it – the bungalow where I grew up sits on a corner lot with two cars in the driveway. My neighborhood of 80 single family homes has no sidewalks, partially because traffic density is low, but mostly because there’s nowhere to walk to within a 30 minute radius. My school is over an hour’s walk away, more than double that in the winter through snow up to your knees in places. Most of my friends live nearer to school, or in the neighboring suburbs of Whitby and Ajax, 10 or more kilometers away. Needless to say, I never walked to school or to my friends’ houses; this is cartown! We drove!

The physical nature of suburbia makes everyone dependent on the automobile, and those who can’t afford cars or are too young to obtain a driver’s license are doubly dependent. While I was under 16 years of age, I relied on my parents to drive me everywhere. The hour, minute, and second that I turned 16 years of age I rushed to the local DriveTest centre to apply for my “G1″ learner’s permit. According to Ontario’s graduated licensing system I had to put in twelve long, torturous months of parent-accompanied driving under my “G1″ before I would be eligible to apply for the “G2″ license – the holy grail of licenses which allows the holder to drive unaccompanied.

You have to understand – for a suburban seventeen year old, obtaining that “G2″ license card wasn’t just a little logistical detail in a system of automobile licensing designed to keep the populace mobile and safe, it was 45 square centimeters of pure unadulterated independence, forged in plastic.

Chris Bradshaw, Vancouver native and co-founder of Ottawa’s Vrtucar car-share, once explained car-love to me in a way that makes a lot of sense. Thinking back to my own relationship with the car as a kid growing up in suburbia I could see Chris’ point that we have let the car become so much more than just a machine for connecting point A to point B. Access to a car has become a bargaining chip in parent-teenager negotiations; something which can be awarded for good behavior, or taken away for disobedience. As such, car-ownership has become a symbol of independence, from your parents first, and from social transit solutions second. Somehow, we’ve let the right to drive become entangled with one’s sense of self-reliance and freedom. We love cars like we love feeling free!

This seems to me to be a classic case of yearning for that which you have historically had limited access to. You never want to give up what you’ve worked so hard to obtain!

One proposal to change this dynamic is to lower the barrier to automobile access for young people; to frame automobile access not as some sort of reward, status-symbol, or light at the end of a dark tunnel of mobility-oppression, but as something commonplace which everyone has access to equally. Take away the prestige and the car-lust will go with it. Car-sharing services like Ottawa’s Vrtucar and Vancouver’s Co-operative Auto Network seem like ideal ways to improve automobile access but they are being hampered by the insurance industry; the insurance provider which insures Vancouver’s car co-op requires that drivers be at least 19 years of age, and in Ontario at Vrtucar the minimum age is 23 – much too late to have any significant impact on a young person’s perception of car-ownership. Unless we organize to effect change at the level of automobile insurance, I don’t see this dynamic changing on its own.

But wait – there’s new hope! Improvements in battery technology, electric motors, and in the legislation regulating the use of electric vehicles have spurred a groundswell of EV availability and ridership. Electric skateboards, power-assisted bicycles, and low-speed electric motorcycles have become affordable, available, and accessible to young people longing for personal mobility. The legislation is such in BC that you need only to be 16 years of age and be wearing a helmet to drive all but the largest and fastest EV two-wheelers. EVs are fast, fun, have storage and style, and are easy on the environment – and the pocketbook!

If you ride an EV of any kind, or if you simply want to learn more about EVs, come out to participate in Vancouver’s own monthly EV ride, “The Kilowatt Hour.” RSVP for the ride today at http://ev.meetup.com/1

This was originally published as a guest column at ChangeEverything.ca