⇥ WordPress, the GPL and cherries on top

The WordPress community is abuzz with news that the WP Foundation has essentially gone to war with the makers of the Thesis WP theme. The substance of the argument, as I understand it, is that the makers of WordPress claim that themes, since they rely on WP’s GPL’ed code to run, must be covered by the GPL as well because they are derivative works. Thesis, on the other hand, is distributed under a commercial license, therefore violating this tenet.

I have, in the past, expressed my dislike for the GPL, which, inevitably, colours my “legal” opinion on the matter—though, I assure you, this post is not about the GPL and I have absolutely no intention on engaging on a debate on the license. Write me or comment on the GPL and I will simply not care—you’ve been warned.

Legal opinions abound

As always when a legal matter is involved, everyone and their dog is giving an opinion. Matt went and asked the Software Freedom Law Center to officially render theirs, and they came through, true to their name, with a nine-paragraph letter that illustrates how themes are, in fact, derivative works covered the GPL.

Arguments on the other side of the fence typically focus on the fact that themes are not derivative works, or because of the fair-use doctrine¹.

Personally, I find the SFLC’s argument very weak from a technical standpoint—particularly in the citation of the use of include (which is not a function²) as justification for their claim that themes are derivative works. Includes are designed specifically to create interoperability between different programs—in the world of PHP, where there is no concept of “binary,” they are the equivalent of dynamic linking.

One would have to physically copy code between projects, or physically include files from another project in a new work, in order to create a derivative work in this context, and to claim that themes do this is simply ridiculous because WordPress is designed to be expanded in precisely the way that themes are developed. To impose the GPL on themes—unlike, say, imposing it on a fork of WP itself, which would be perfectly logical—is to restrict a developer’s ability to interact with a particular piece of software and this would constitute an artificial limitation on a developer’s ability to interact with WordPress, which could give grounds to a fair-use claim.

Obviously, the SFLC probably believes that any form of linking or reliance of a piece of software upon another creates a derivative work, and they may well be right. Larry Rosen of the OSI believes that the determination of what constitutes a derivative work in the context of software should also take into account the element of intent—that is, whether the author of the work in question wrote their software in a specific way because they were aware of and attempted to circumvent the application of a license to derivative works. If he’s right, building a theme cannot possibly constitute the creation of a derivative work—again, WordPress is designed to be expanded, and it cannot taint downstream work that is not a direct derivation of itself, much like Linux cannot impose the GPL on commercial drivers or on commercial products built on it³).

Legal opinions are meaningless

Here’s the kicker: what I think is meaningless. What Matt thinks is equally meaningless. And what the SFLC means is most meaningless of all.

I am not a lawyer, and neither is Matt. The SFLC, which has an obvious bias towards the enforcement of the GPL⁴ is made up of lawyers and they, more than anyone else, should have made sure to cover their collective ass and Matt’s by explicitly pointing out that there is but one legal opinion that matters: that of a judge and jury.

Unless the WP Foundation ever takes the makers of Thesis to court, therefore, all these “legal opinions” have absolutely no legal value whatsoever. They are nothing more than a form of posturing and an exercise in public relations in the world of court opinion, to cite Adlai Stevenson.

And that is what puzzles me, because from a business and strategic perspective, the WP Foundation has nothing to gain from this exercise. Let’s look at the possible outcomes:

• The WPF could sue and lose, and look like idiots who spend their time litigating rather than innovating (which is what they should stick with).
• The WPF could sue and win—and still look like idiots because the implications of themes being covered by the GPL would have an enormously chilling effect on the professional WordPress community. More than that, they would have to sue every infringer, or risk looking like they are pursuing some secret Matt-centric agenda.
• The WPF could do nothing and look like warmongering zealots—belligerent only in words, all they would achieve is a polarization and eventual schism of the community between those who believe that software is free, and those who believe that GPL is about freedom.

The way I see it, there is no possible outcome of this diatribe that could benefit the WPF, which is why I am puzzled.

Incidentally, you may be wondering why I think that GPL’ing the themes will be problematic for the entire community. Well, what I am wondering is: how will it affect the thousands of freelancers who create custom one-off themes for clients?

This is a big problem, because the GPL does not attach itself to a derivative work until you distribute it—this is why, for example, you don’t need to release GPL code if you hold copyright and use it for your internal purposes. If you are a freelancer, however, you normally hold copyright on a theme you develop but don’t use it for your own purposes—you give it to a client under some sort of license… which is exactly what amounts to distribution.

Unless you assign the copyright in your work to the client (and why would you want to? You are a freelancer, not an employee, and giving up copyright in a particular work is tantamount to giving up your trade secrets), you are, effectively, distributing the theme you developed, which now becomes covered by the GPL. Should the theme somehow include code that is owned by the client—for example to interface to one of their internal systems—that code might well be covered by the GPL, too, thus opening a can of worms of elephantine proportions: the client has gone from ordering a bunch of templates for its website to having to open-source and distribute its own proprietary code. If I were said client, I’d probably be switching to another CMS right now.

Naturally, the WPF could say that it won’t pursue those cases, but they don’t get to choose what the GPL attaches itself to or not—remember, the GPL is not GPL’ed itself: you can’t modify it, you can only use it or not use it. And the GPL says that derivative works must also be released under the GPL period.

So, what the WPF thinks the GPL applies to and what it actually applies to could be two completely different things. Therefore, while you may not get sued by the WPF for writing a proprietary theme specifically for a client, the GPL may still apply to it and all the code that is part of it—which means that, if your theme uses a client’s proprietary code, you’re both in potentially big, big trouble.

So, what should the WPF do?

First, it should back off; this fight isn’t helping anyone—least of all the WPF itself.

Second, it should draw very clear lines in the sand:

1. WP is released under the GPL, and so has to be any direct contribution to core or fork thereof.
2. Themes and plugins are not derivative works and are not covered by the GPL and can be released under commercial licenses.
3. Themes and plugins distributed by wp.org must be released under a GPL.

This creates a fair and balanced set of clear guidelines for everyone to follow: if you want the exposure of wp.org—for example to increase your reputation and credibility as a WP expert freelancer—you have to release your code under an open-source license. If you want to distribute your code commercially, the burden of promotion and public relations is on you since the community doesn’t benefit directly from your work.

Now, I anticipate that some will simply say that, under my proposal, nothing would prevent commercial vendors from circumventing the fact that core is GPL and simply using plugins to effectively fork WP without forking it. Well, nothing has prevented them from doing that until now⁵, so how would this be different, other than giving developers and freelancers the confidence that the WPF board isn’t going to wake up on the wrong side of the bed one day and start suing people left and right?

Maybe the RIAA can get a discount

Recording Industry vs. the People:

The RIAA paid Holmes Roberts & Owen $9,364,901 in 2008, Jenner & Block more than $7,000,000, and Cravath Swain & Moore $1.25 million, to pursue its “copyright infringement” claims, in order to recover a mere $391,000. [ps there were many other law firms feeding at the trough too; these were just the ones listed among the top 5 independent contractors.]

Embarrassing.

Not really. From a corporate perspective, what choice do you think these executives had? Had they done nothing, they would be in breach of fiduciary trust—they’ve been pushing for these laws and now they have to enforce them. $17 million is chump change compared to losing their jobs and facing a shareholder lawsuit (especially given that it’s not their money).

The real tragedy here is not that the DMCA exists, but that the RIAA has made a major strategic mistake in utilizing it. If they only went after people who infringe copyright for profit, I don’t think anyone would have a problem with their legal actions. If you think that someone making a million illegal copies of a DVD and selling them is doing a good thing, you have some serious ethical issues.

But the RIAA chose to go after individuals, which is as pointless from a financial perspective as it is self-destructive from the point of view of public relations—and now it’s too late to truly change course and gain any public trust.

⇥ A little bit of Apple, a little bit of Adobe

There seems to be a distinct lack of perspective in the whole Apple vs. Adobe war—perhaps it was inevitable that something like the by now infamous Clause 3.3.1 of the iPhone OS SDK agreement would polarize people so much.

First of all, because I suspect that my readers will make a big deal out of it, I stand by my previous post on the whole Apple thing. Feel free to disagree, but even the introduction of the new clause, which limits “sanctioned” iPhone OS apps to those that are written in a handful of official Apple languages, doesn’t limit your ability to tinker with the OS. It does, of course, limit your ability to deploy, which, depending on what your ultimate goals are, may be a significant problem—but it doesn’t prevent you from writing apps for the platform, including those you develop using one of the “forbidden” tools.

A little bit of Apple

Some of the arguments that the Apple camp uses to justify the existence of the new clause seem a little specious to me. Gruber’s analysis on why the clause exists¹ is probably spot on, but his conclusions are a little disingenuous. Section 3.3.1 was clearly introduced to developer lock-in and protect Apple’s significant profit margins on the sale of iPhone OS devices—after all, cross-platform development tools like Flash or Titanium are about levelling the field by deploying across multiple devices with a single codebase; if apps look and behave the same way on multiple platforms, the argument in favour of spending your money on Apple devices loses much of its value.

What I haven’t seen mentioned is that §3.3.1 also ensures hardware lock-in, because now there truly is no way to develop software for iPhone OS unless you’re on a Mac. This was true before, as well, but only to a certain extent. Prior to the new agreement being introduced, if you chose a cross-platform development tool, you could conceivably run a team on Windows or Linux and then buy a single Mac—even an entry-level Mini would have done—for building, testing and deployment. Your only choice is now to be an all-Mac shop.

The leap that Gruber—and Jean-Louis Gassé, in a piece that just came out this morning—make from realizing the §3.3.1 is about lock-in to claiming that cross-developed applications are inferior, either in terms of performance or quality, is laughable. There are plenty of hideous apps in the App Store—most of which have been built with the native tools. Tools don’t make developers—they are just tools. Twenty years of experience in the IT industry tell me that poor programming skills will show no matter what platform software is written on.

Besides, if ensuring quality were really Apple’s ultimate goal, they have all the tools—legal and otherwise—to do so today, without the need for any new clauses. They could, for example, start enforcing their own human interface guideline policies; there are plenty of apps that blatantly violate them² in the store even though they have been built using sanctioned tools. Ditto for performance—Apple’s own mail client struggles, at times, when selecting multiple messages even on the iPad, which is probably the fastest of all iPhone OS devices. If these are the things that matter to Apple, §3.3.1 is not the answer to them.

As for the topic of this being Adobe’s comeuppance for snubbing the Mac when that platform was struggling, I have no comment to offer—mostly because I wasn’t either a Mac or Adobe user at that particular point in time. But it seems to me that Steve Jobs has shown himself to be a much-too-focused executive in the last ten years to embark on personal vendettas. Even his spate with Michael Eisner over Pixar was, in my opinion, much more about shrewd negotiations than personal antipathy³. Alas, the vengeance, if it exists, is only in Steve’s brain—a place I respectfully want to stay out of.

A little bit of Adobe

The bitterness on the Adobe side of things is a little disproportionate to the events, I think.

Claiming that Apple is out to damage the launch of CS5 is just plain silly. Sure, the iPhone OS 4 event might have been a little suspiciously timed, but Flash’s ability to cross-compile to iPhone OS is a relatively minor feature of CS5. As a developer, Flash does little for me—it’s a designer’s tool. My interest lies more with tools like Flash Builder or AIR2, which make a heck of a lot more sense to me than Flash itself. As far as CS5 goes, I’m much more fascinated (and not a little freaked out) by Photoshop’s new content-aware fill than what Flash does.

What’s more, I wouldn’t rule out Flash as an iPhone OS development platform altogether. True, you can’t sell the software you write with it on the App Store, but that ignores a huge segment of the market for which Flex and Flash are ideal platforms: internal-use applications. I have, in the past, mentioned that I believe this to be AIR’s best market: scenarios in which an IT department needs to deploy tools to a heterogeneous, but captive, environment. If I were building a management console for a company of any size, I would not hesitate to recommend that they use Flex and AIR for it, even for iPhone OS deployment. Bypassing the App Store in these cases is not just easy—Apple gives you all the sanctioned tools you need—but also desired, and the ability to build a single codebase could signify major savings for any company without necessarily compromising the unique per-device experience⁴.

By the same token, stating that Adobe should simply stop making products for Apple platforms is just plain stupid. Never mind that Mac users are likely a large source of revenue for the company—screwing customers over hardly seems to be the way to solve this issue. You’d think the whole Kindle-vs.-iBooks spate would have taught these people something.

Kevin Lynch, Adobe’s CTO, has offered a fairly measured response to the §3.3.1 issue—but I must admit that I, for one, was disappointed that he should be the company’s spokesperson on what seems to me like a business, rather than a technical, issue. He should have focused on the technology aspects of CS5 and leave the CEO to address Apple’s perceived shenanigans.

Some of the responses from the company’s evangelists were regrettable, but, in my opinion, understandable. It must be difficult to be so focused on a product launch only to see your thunder seemingly taken away by a company that has no immediate reason to. Still, I prefer Ryan Stewart’s approach of looking at this as what it is—an opportunity to improve the Flash tooling.

By way of disclosure, Adobe is a client of Blue Parabola. I also write iPhone OS software. Take your pick of biases.

¹ I am probably overreacting, but I can’t help thinking that Gruber’s analysis is a little too spot on. I absolutely don’t want to accuse him of anything, but the fact that he was able to hone in on that one clause of the agreement as the 4.0 beta had barely become available raises substantial questions.

² I don’t mean here that all apps need to look exactly the same, but that they should offer a consistent interface across the entire platform. Human interface guidelines are about user experience—not colour and pictures. They are what gives “good” OS X applications that distinctive “Mac” feel.

³ Say what you will about Eisner, but he was exactly the kind of person that Disney needed at a point in time when its management spent most of its day attempting to wonder what Walt would do. He was brash and abrasive—and managed to bring order to what had become a chaotic company. And, when he was finally done with what must have been one of history’s best turnarounds, he was shredded to pieces by the Disneys with little regard for his accomplishment. Luckily, he’s been replaced by Bob Iger, who seems to be just as capable without grating people the wrong way.

⁴ Of course, nothing prevents stupidity from making people write a single app that looks bad on all platforms—but that has, again, nothing to do with the tools and everything to do with incompetence.

⇥ HipHop: What you need to know

By now, unless you’re living under several hundred metres of rock,  you’ve probably heard that Facebook has released HipHop for PHP, a tool that compiles PHP into C++ with some interesting claims of speed improvement. The thickness of unawareness-inducing rock may have to be lower to know that php|a and BP have announced our full support for the project with a number of initiatives that we’re going to roll out over the next few months.

I have known about this project for a little while—Facebook was kind enough to invite me, along with a few other community members, to their office for a demo a few weeks ago. They gave me a copy of HipHop to try out, and I have been playing with it for the last few days.

What it is

First, a few random notes on how HipHop works. Haiping has done a great job of providing in-depth coverage in his post on the FB blog, so here are the CliffNotes:

• HipHop transforms PHP into C++ code, which can then be compiled into a self-contained executable. The tool supports a large percentage of the current PHP 5.2 spec, with some obvious exceptions, like eval().
• The tool attempts to find the maximum level of optimization possible for a given scenario using its own static analysis tool. For example, if it detects that all operations on a given variable are homogenous in type (e.g.: they are all integers), then it uses the corresponding C++ data type to provide maximum speed and memory enhancement. Where this is not possible, it implements its own variant type, equivalent to a zval.
• HipHop doesn’t currently have its own PHP runtime—nor is it based on Zend Engine. It compiles everything to C++ and uses its own set of C++ library to provide the necessary support.
• Once compiled, HipHop provides its own web server (a CLI interface is also available). It does not use (or require) Apache or any other server. Of course, this doesn’t preclude you from running one or more HipHop projects against separate ports on the same machine and then use Apache (or Squid, or any other server) to reverse proxy to them.
• HipHop doesn’t currently support Windows (though, personally, I’d be surprised if that didn’t eventually change—it just so happens that FB built for the environment they use internally).
• The entire tool is intended to be a drop-in replacement for the PHP runtime—as long as you do not use any functionality that it doesn’t support, you should be able to compile your existing site and run it.
• Facebook is using HipHop in production to handle 90% of their traffic.

What it’s going to do

HipHop has the potential to be an incredibly disruptive product in the PHP landscape. If your company runs a PHP application that requires more than two servers (you’ll want two just for redundancy), you have no reason not to explore using HipHop. If Facebook’s claim of a 50% reduction in CPU usage means you could, potentially, get rid of 1/2 of your PHP machines with a minimum of investment. You don’t need to be Facebook to draw a huge advantage from this technology. Perhaps this one-to-one reduction is not apt, but even 40% or 30%—much more realistic—is major, and a truckload and a half more than any other existing PHP-related product can offer at this point.

Clearly, this argument can be flipped around: you have every incentive to make sure that your application runs with HipHop—which could give Facebook a unique opportunity to exert significant control over the way PHP evolves.

You might, at this point, think that this is not the first attempt at a PHP compiler—in fact, there are other compilers commercially available. Heck, even I wrote my own experimental compiler several years ago (in fact, I had a discussion about my experience with some of the Facebook team members about this a while back, presumably while they were researching HipHop)—and that ultimately it won’t make a difference.

But HipHop is neither experimental nor unproven, and it’s free; it is used, in production, by the second-largest site on the Internet—and make no mistake about it, there is no smoke-in-your-eyes (not to mention other body parts) sleight of hand on Facebook’s behalf; their site is written in PHP by PHP developers, without the help of large numbers of custom extensions. In fact, their goal is precisely to allow their developers to continue using PHP—which they consider the nimblest web development environment—without compromising their ability to grow at the current pace in a financially responsible way.

If you think about it, that makes a lot of sense from a business perspective: PHP is simple, flexible and easy; with HipHop as a drop-in compiler, FB can achieve an immense immediate benefit with essentially no disruption to their operations. The question now becomes: shouldn’t everybody else?

⇥ Upheaval without wires

If you came here for advance information or predictions about Apple’s much discussed table, I am afraid I have neither. In fact, I am fairly sure that what I am about to tell you is unlikely to happen, so, there you are.

On the other hand, I have certain hopes for the product and one, in particular, is something that I haven’t seen anyone in the media discuss: could the Jesus Tablet revolutionize the way we buy and use wireless data?

Everyone agrees with the fact that the tablet will have some kind of 3G or 4G wireless cellular connectivity, but they all seem to take for granted that network access will be provisioned the same way it is done with the iPhone.

The tablet, however, is not a phone—quite the contrary—and, therefore, it’s perhaps a good idea to ask whether Apple may not be looking for ways to create an even more captive market.

To understand what the implications might be, one only needs look at the Kindle. It hasn’t occurred to me until recently that the killer feature of Amazon’s reader is not the e-ink screen, or the vast selection of books—it’s the fact that it makes accessing a cellular network completely seamless: there are no contracts for you to sign (except the one with Amazon), no data fees to pay (except the ones you pay to Amazon as part of your purchases) and—most importantly—no roaming fees to deal with.

In other words, even though it doesn’t look like one, the Kindle is a cell phone that works the world over through a single provider that is not your cellco. In fact, looking at Amazon’s recent announcement of its revised royalty scheme for the Kindle, you can see that they are planning to charge $0.15/MiB for data transfer, regardless of where the user is in the world. To put things in perspective, the lowest price that is available to me while roaming in the States is $1/MiB—and that’s if I pay a $10 monthly fee to get it reduced from $6/MiB, if I sign a long term agreement and if I agree to pay on top of my regular voice and data plan.

Compare this experience with the absolute hell that dealing with your current cellular company is, and you will see that there is an opportunity, for a sophisticated player, to create a wave of unprecedented disruption in the wireless market.

If Apple were to sell the tablet and make a data plan available through Apple, a number of really important things would happen:

• First, its users would become entirely captive—no messing around with third-party companies, subsidies, and the likes
• Second, a clueful company would, for the first time in history, be in control of a wireless experience end-to-end. Just like the iPhone’s killer feature is the App Store, this could be the tablet’s one defining characteristic
• Third, Apple’s immense buying power would bring costs down to a level that is going to be difficult to beat
• Fourth, the fact that it doesn’t look like a phone doesn’t mean that the tablet couldn’t work like one—and without pesky wireless companies dictating terms, no-one would prevent customers from installing Skype or a SIP client on their systems
• Fifth, Apple could easily integrate this service with others it already provides (MobileMe Data?)

The disruption of this approach would be nearly total: because customers purchase service from Apple, the underlying network provider becomes little more than a curiosity, and it’s not unthinkable for our friends from Cupertino to eventually set up their own global wireless network.

Of course, I have no illusion that it’s highly unlikely for any of this to happen—I mean, the wireless companies cannot possibly be so shortsighted to let this happen, right?

Right?

Image credit: Tablets by swimboy1

⇥ The story behind TEK·X’s Charter Ticket program

Unless you’re living under a particularly large rock, you’ve probably heard that we are doing a special promotion, which we call Charter Ticket Program, that makes it possible to purchase a full-experience TEK·X ticket—valid for both the main conference and tutorial day—for $650. The catch (if you want to call it that) is that the special is only valid until we announce the schedule—so, effectively, you need to put a lot of trust in our ability to attract top speaking talent and stitch together the schedule of a conference that you will want to attend.

Given the incredible response that our call for papers has received—over 9 proposals for each speaking slot—I have no doubt that we will be able to create a schedule rich in variety and topics that are very relevant to PHP developers from all walks of life. If anything, we’ve had a really hard time finding room for all the talks that we wanted to be part of TEK·X and, although I believe that my colleague Keith Casey will have some hopefully welcome news on this subject to share in a few days, we’ve run out of room much sooner than we ran out of good talks to approve.

The reasoning behing the Charter Program is very simple: we recognize that there is a core of attendees for whom our conferences have become an opportunity to meet up with their peers and learn what’s happening in the PHP world. In fact, there are some who have been to all of MTA’s conferences, so we felt that they deserve a little some extra special.

The Charter Program is designed specifically for these folks: at $650, the current price of the tickets is almost half the price of a regular ticket at the door—and $350 less than the lowest early-bird price. It is the lowest price you will be able to secure a spot at TEK for—an opportunity for a great deal if you put a little faith in the folks who have brought so many memorable events to the PHP community.

To take advantage of the Charter Ticket Program and save as much as 45% over the price of a full-experience ticket, you must sign up for TEK·X before January 6th, 2010, when our schedule will be officially announced.

⇥ TAB’s new layout

Over the past few weeks, I have toyed with the idea of giving The Accidental Businessman a new look. I don’t dislike the current theme, but, as I mentioned in an earlier post, it’s a bit too “angular” for my taste.

Over the last few days, therefore, I stole a few minutes of free time here and there to come up with a new design. It turned out to be an interesting experience, both because on this site I have a degree of freedom with experimentation that I can’t really afford anywhere else (not necessarily a good thing) and because of the technical challenges of realizing my vision for the site on current browsers (the site works with IE8, FF3.5 and Safari 4).

Maximum space

My first concern was to maximize the space available on the screen for viewing. Screen reading is quite difficult—ironically because there is usually much more space available than the comfortable reading angle that the human eye can accommodate.

The default solution to this problem is to confine the reading area to a small horizontal section of the screen; this works, but it’s also very inefficient: it’s the physical-world equivalent of printing a sixty-character line of point-10 font on an A2-size sheet: inefficient, wasteful and difficult to handle. The way I see it, the typical web layout works if you like scrolling. Me, I like to open a webpage, lean back on my chair and read.

Speaking of real world, it occurs to me that newspapers have already solved this problem—and, in so doing, have established a number of rules to make the task of as much space available as possible in a manner that is both efficient and aesthetically pleasing. Therefore, the new TAB layout attempts to mimic the look of newsprint as much as possible, keeping in mind that, of course, my blog is not printed on paper (therefore, some concessions to life online—such as leaving some room for comments).

Layout

The new layout makes heavy use of Javascript—according to my statistics, practically all my visitors have a Javascript-capable browser and leave JS enabled, so I have absolutely no problem with taking advantage of a bit of scripting to achieve my goals¹. Through the magic of jQuery, the content is automagically laid out across multiple columns—their number determined based on the site of the browser window—and paginated across multiple screen, which you can navigate without a browser refresh².

I decided to keep a comment area on the right-hand side only so that comments can be visible at all times. I am unsure as to how good this is—on a screen big enough, it seems to work fairly well, but at lower resolutions it robs much of the content area from the rest of the article.

Typography

The proper use of type is as important on the web as it is on paper—even more so on the former, perhaps, because of the limited resolution at which we are forced to view type online. Unfortunately, typography is often completely disregarded by web designers—I’m not sure why this is, but the focus seems to always be on graphical elements that, at the end of the day, have little or no importance: if your header looks colourful and has all sorts of bells and whistles, but people can’t read what in the body of your site, they are unlikely to be very happy.

In choosing a typographical design for TAB, I started from the most excellent Baseline CSS Framework, which, much like newspaper typesetters, uses a simple set of rules to ensure that multi-columnar text will line up properly on the font’s baseline. The framework’s setup is actually fairly simple: each style is an integer multiple of the base font size and line height, resulting in a text flow that lines up perfectly across multiple columns—in fact, as long as every element on a page follows the same rule, images and practically any other type of content can be added to an article and still maintain the same baseline alignment.

The script also support a very basic form of orphan and widow control, so that a heading should never appear either at the end of a column, or (even worse) “broken” across two columns. I am investigating ways to improve on this particular piece of technology to improve paragraph control well beyond the basics, but I fear that some of the calculations required will slow things down too much. Unfortunately, the level of control that CSS affords over sub-paragraph data (at least in CSS2, which is the target here) is not quite as good as it could be.

Finally, you will note that the text in the columns is justified. I usually dislike full justification in a browser because hyphenation is not a possibility and, therefore, there are often unsightly gaps between words that make reading a challenge. However, using the most excellent Hyphenator package by Mathias Nater, I was able to add hyphenation as well, which closes the gaps between words and makes text flow very nicely, providing both a pleasant look and a practical, readable format that should be easy on the eye.

Limitations

The theme is still quite rough around the edges. First of all, the contrast is not quite where I’d like it to be—I feel that the design is easy on the eye, but could probably use a little more punch. I’m not much of an expert on colour theory, so I’ll probably be nagging my good friend Arbi, whose worst day was the day I acquired a copy of Photoshop, for some advice. The layout of pages other than main articles needs some adjustment as well.

From a technical viewpoint, the method used to lay out the columns is a bit brutal—I am essentially cheating by duplicating the content over and over and only showing selected portions of it as appropriate—which works visually, but makes things like cutting and pasting a challenge³. Rendering performance under Internet Explorer is also a problem—although that’s something I think can be fixed by optimizing the Javascript code a bit.

Thus, think of this as an experiment in the works. I welcome your comments, suggestions, bug reports, and so on. I do, at some point, plan on making this an actual WordPress theme—it’s still too “Tabinized” for public consumption at the moment, but feel free to borrow, copy and use at will; none of the code or stylesheets on this site are minized or obscured and they are explicitly released under a BSD-like license (unlike the content itself).

Photo credit: A Stack of Newspapers, by DRB62

¹ Of course, scripting only affects the layout visually and not its functionality or content—thus, if you use an assistive device, such as a screen reader, the site should remain easily accessible.

² This is my idea of “good pagination.” I hate when sites split content across multiple pages as a way to force reloads so they can serve more ads.

³ CSS3 is going to make this type of layout much easier, but support for flowing controls is still a way off in several browsers.

⇥ Old school task management

Nothing beats paper for personal task management (except, possibly, your spouse)

The biggest lesson in user interface design that I have ever received is, to this day, a little something that happened approximately eleven years ago.

At the time, I remember standing in the headquarters lobby of one of Canada’s largest insurance companies, uncomfortable—as I always am—in my suit, right next to my CEO. We were waiting for a meeting with the company’s CIO that we had tried to schedule for two months. We were prepared; we were early enough to show that the meeting mattered to us, but not so early that we would look desperate. We were ready.

Unfortunately, our host wasn’t. The receptionist informed us, politely but with that condescending look of someone who has seen far too many supplicants make far too many sales calls, that the CIO wasn’t expecting us today and wouldn’t be seeing us after all.

My colleague—a person who could teach anyone business smarts simply by standing next to them for a short period of time—decided that we hadn’t donned our best suits, driven through that particular brand of hell that city dwellers jokingly refer to as “traffic” and spent $30 in parking to be brushed off so easily. “He doesn’t know my cell number… I bet if I call his direct line he will answer¹,” he stated.

That sounded good to me—I had paid the $30—so I opened up my Cassiopeia and started looking for the guy’s phone number. I was pretty good with that little device—and I never got tired of showing it off (much like an iPhone until a few months ago, it made for an excellent conversation starter at business meetings). It only took me a minute or so to pull up the number and, once I located it, I looked up to dictate it to Rick.

Except, of course, that, while I was deeply busy getting off on electronics, my friends had already whipped out his $2.99 pocket phone book, found the number, called the CIO and very gently tore him a new waste management system. Before I knew what had happened, we were on our way up to the executive floor, and my Cassiopeia was on its way down to the trash.

Fast forward ten years…

Things have changed considerably since that episode (incidentally, the meeting was a bust—I only remember what happened specifically because it had a cathartic effect on my appreciation for ergonomics), but, in many ways, software is still too often a solution in search of a problem.

This is the reason why, even after all this time, I manage all my day-to-day tasks on paper. I’ve tried a number of fancy (and not-so-fancy) task management systems: GTD-compliant systems, OmniFocus, Things, and so on. I’m sure that these applications and methods do wonders for scores of people, but, for some reason, they just don’t work for me.

You see, daily task management is not really about knowing what you need to do; it’s about doing it. A to-do list in any form isn’t going to help you “remember” the things you have to do—let’s face it, you know what you have to do; most of the time, you’re just too lazy to actually do it. Task management software is helpful in keeping track of what you need to do, but it lacks in what I jokingly refer to as the “spouse factor²”—it doesn’t nag you enough about sorting through your tasks and taking care of them.

Paper won’t start calling you in the middle of a client meeting to remind you that you need to pick up the milk on the way back home, but it has two great advantages: first, it’s extremely portable and, second, it cannot be hidden behind another window. Third—yes, I am cheating—it’s as of yet unbeaten as a mind-mapping tool, especially when coupled with that most noble of writing instruments, the pencil.

Task management, old-school style

Managing time is a complex matter. Some people are naturally good at it, while others, well, not so much. I belong to the second category and, therefore, a good management system is essential to get me through the day. For the benefit of inquiring minds, thus, this is how I organize my day:

1. Once proper grooming has taken place and I am sufficiently caffeinated to write something that I will eventually be able to read later, I start working on my to-do list for the day. This usually takes place after I do my morning e-mail triage—just in case there are some truly urgent and unexpected tasks that I need to be aware of.
2. I start by copying over the unhandled items from the previous day. Then, that list goes into the trashcan.
3. Next, I write down whatever new items I need to take care of on that particular day—consulting liberally with my calendar, just in case I forget something.
4. Next, I sort items according to two criteria: urgency and palatability. Urgent tasks need to take precedence, as do those that I’d rather avoid—that way, I have something (the tasks I actually like to do) to look forward to.
5. As I go through the list, I try to find a “daily goal” of sorts—my TDL is usually much longer than my day reasonably allows, and some long-term tasks need to be taken care of daily, regardless of what precedes them. Thus, I further sort tasks between “must do,” “should do” and “can go to tomorrow.”
6. As the day progresses, I erase tasks as I complete them. The erasure is also “old school”—I just scratch a line across the item. That way, it doesn’t automatically disappear—it sticks around as evidence that I have actually done something.
7. At the end of the day, I go through the list one more time to ensure that I haven’t forgotten to take care of some truly urgent tasks. Otherwise, the TDL will tell me what I have accomplished over the course of the day—and the remaining tasks will be there for me to work on tomorrow.

That’s all there is to it. If I need to work outside the office, all I need is a piece of paper and a pen. Best of all, the to-do list is right there, in front of me and at the top of my work pile on the desk. It’s impossible to ignore, even without pop-up notifications and stereo sounds.

How do you manage your time? Much like my obsession with finding out how others organize their desks, I am curious to see if I can learn a trick or two to improve my time management.

¹ Remarkably—even for the time—the person we were visiting didn’t have a secretary, even though he held a C-level position at a major corporation.

² Intended in the most gender-neutral way possible. I am quite sure that husbands can be as annoying as wives, regardless of the gender of their better halves.

Photo credits: My to do list by ezs

⇥ Selling software in an open-source world

How do you sell software when it's free?

Last week, Zend’s marketing department saw fit to send me an e-mail—the third in so many weeks—touting the fact that the upcoming Zend Server 5 will support job queueing¹ to offload requests either to another process on the same server or to another server altogether.

Undoubtedly, this is a great feature, not the least because it begs a little bit of simple business analysis of how difficult it is to create a market for products in an open-source world.

First of all, a simple look at the economics of this feature reveals that, in itself, it cannot be a determinant in the purchase of Zend Server². The reasoning is fairly simple: a copy of the lowest-level subscription for Zend Server costs $1,195. You can, however, get queuing support from a variety of other sources—most notably Amazon Web Services, which sells queuing requests for $0.01 per 10,000 requests. In other words, you’d have to need to make more than 1,195,000,000 queuing requests in a year to justify the purchase of Zend Server if all you ever wanted was queuing support.

Therefore, queuing needs to be part of a larger set of features that, taken together, make Zend Server a compelling and unique product. However, none of its features do this—there is practically nothing in ZS that cannot be obtained elsewhere for a lower cost (or for no cost). What’s more, Zend cannot lock any new feature it adds to its products because it can be easily replicated by just about anybody else.

Case in point, on the very same day when I received Zend’s e-mail, Jonathan Wage tweeted about a library he built on top of Doctrine to manage message queues using a variety of different storage media. So here we have, in the same period of twenty-four hours, a company that is trying to sell me a solution that a person claims to have developed and is making available completely free of charge.

Of course, this comparison represents “all kinds of unfair” towards Zend—their solution could be better implemented, more reliable, or scale better.

Or, perhaps, I could point out that they are not, in fact, selling the software at all.

Software is worthless—service is everything

In an open-source world, the capital value of any piece of software tends towards zero—not only because you others get the software for free, but because vendors cannot lock in any feature that makes it impossible for anyone else to recreate the same functionality and give it away at no cost. Microsoft has proprietary control over Windows and can, therefore, decide which features it allows third parties to replicate. Zend has no exclusive control over PHP and, therefore, enjoy no such privilege with its products. Nor is this a problem that is specific to Zend—any other company that works in an open-source space has to deal with this particular issue in one form or another.

The only real product that a company like Zend can sell, therefore, is the peace of mind of knowing that there is someone that your organization can turn to for assistance when things stop working. Not being a Zend customer myself, I can’t say how well they do this, but I do find it interesting that they continue to define themselves as a product company and that they don’t seem to place any emphasis on their services.

I understand that the need to sell products is primarily one of scale—it’s difficult to convince an investor that they should give you their money unless you can show exponential growth, and a service-oriented organization simply cannot achieve that. However, when your product is, essentially, an extended form of support, you need to build an organization that has service at its core—it’s only through services that a company will gain acceptance for its products and achieve the scale its investors demand.

This is nothing new, of course—organizations as large as the largest software vendors in the world have highly developed service organizations that, while not representing a significant revenue centres, act as a springboard for the sale of the company’s products. This is true both in the open- and close-source markets—think about the size of Microsoft’s Consulting Services division or the importance that a company like Red Hat attaches to the creation of a holistic ecosystem for its products, from certification to training and consulting.

Educate, Penetrate, Accelerate

The importance of services can be best illustrated through the mantra educate, penetrate, accelerate.

Education is an essential part of driving the adoption of your products. It involves the cooperation of marketing, which raises awareness about your products, and training and certification, which promotes competence among your clients. The former without the latter leads to discontent, because your customers won’t be able to use your products. The latter without the former leads to poor adoption, because nobody will know about your products in the first place!

Penetration of the market can only be achieved by a well-tuned and aggressive consulting-services strategy. This is particularly true in the PHP market, which is trending towards a higher and higher level of abstraction in programming tasks—when people invest millions of dollars a year in content management systems, the only way that you can make your products relevant is to make them relevant to those systems. To offset the cost of providing services, a company needs to foster a competitive, but also active and rewarding, environment for its consulting partners, demanding high quality while providing excellent opportunities for profit by reducing some of the costs associates with customer acquisition.

A good service division will lead to acceptance of your products, which is where you can accelerate your growth by selling multiple licenses to your paid products to each client.

¹ I realize that I’m just being petty here, but Zend’s marketing need a severe visit from the Cluebat Fairy—if the best reason you can come up with for trying to sell me a queue management system is that I can eliminate “long-running PHP scripts,” you have failed miserably. To a developer (or, at least, to this developer), queuing has three important benefits: parallelization, prioritization and consistency. In other words, I want to know that I can push messages in the queue so that they can be processed by multiple workers, they can be assigned a specific priority if needed, and that they are not going to end up in some sort of black hole. Offline serving of complex tasks is a consequence of these features, rather than the feature itself—but I digress.

² Of course, you can download Zend Server for free, but that only reinforces the difficulty in creating products for the PHP market.

Photo credits: Girotondo by Luca Sartoni

⇥ Going virtual

Even as a relatively small company, we’re drawing huge benefits from virtualization.

(more…)