Monthly Archives: April 2010

FOSS and Drug Dealing

FOSS. Free and Open Source Software.

Many argue against FOSS saying that Developers should get paid for their work. First of all, “Free” does not mean zero dollars. And second of all, you are short sighted if you think selling code is the only way programmers are paid.

Developers of zero-dollar software get the benefits of control, freedom and experience which can outweigh any money they might make. By control I mean the ability to exactly craft the feature set and API they wish. By freedom I mean freedom from paid licensing and the whim of a software corporation. By experience, I mean that developers have a chance to contribute to a project which may provide professional experience their day job cannot; and it is often a means for a developer to get name recognition.

As far as business models, here are a few that work well with zero-dollar software:

  • Earn community respect for your expertise then make money from speaking at conferences
  • Develop paid modules, features or add ons to the software
  • Provide paid support for the software

Paid software models also work and the FOSS would not shame developers who sell their work. But developers of zero-dollar software recognize that they can personally make far more money selling other services than they can make selling the software itself.

Take for instance a no-name developer who wants to be the sole developer for software that meets a certain need. He or she can release FOSS to a wide audience where the user base is large. The large user base provides opportunity for good feedback and help from others. Then the developer can use one of the business models above.

The developer may go another direction; he or she may charge for the software. In this case of a no-name developer, it is hard to make money. The developer has no name recognition and most users will be unwilling to take a chance and pay for such software.

The problem is a situation like the rumored Oracle decision: where a company takes zero-dollar Open Source Software and starts charging money. It is like a drug dealer: get everyone addicted to the free sample then drop down the price hammer.

Wise up. It is short sighted and disingenuous to change a FOSS-based business model into a paid-software model.

Laptop Keyboards Compared

I have used a laptop for everyday web development most of my career. I am a keyboard snob. A huge keyboard snob.

My favorite keyboard of all time is the classic IBM keyboard:

IBM Keyboard

But no laptop keyboards even come close. In fact, it has been a fad over the last few years to put a 10-key pad on the laptop! How mind-numbingly stupid! I decided to design my own “programmer” laptop. I found the following to be important.

  • The keys I use most often are the 6-key bank (Insert, Delete, Home, End, Page Up, Page Down) and the arrow keys. These I want true to the classic feel.
  • Keep Alt and Ctrl where they should be. Don’t crowd it with “Right click” keys or “Fn” keys. Why would I need to use the “Fn” key while my fingers are on the home row? Move it off to the side!
  • I can handle the Windows/Option/Super key (star key below) between Ctrl and Alt. They are often useful.
  • Separate Esc pretty well.
  • Keep the keyboard and touch pad in the middle of the keyboard. With the currently popular 10-key laptop keyboard layouts, either my wrists or neck become awkward.
  • Keep a middle click button. I use it constantly.
  • Add a nice and somewhat separate area on the touch pad for scrolling.
  • I like the pointing stick between keys g, h and b.

Mockup of my ideal laptop keyboard.
My Ideal Keyboard

Yes, I know: It’s ugly! But I want function. I measure that to be 16.5 inches wide. That is comparable to the 16.4-inch width of a Toshiba laptop with a 17.3-inch screen. For smaller screens, checkout this second mockup. I measure it to be 14.4 inches wide. That is narrower than the 15.1-inch width of a Toshiba laptop with a 15.6-inch screen.

Mockup of a narrow version of my ideal laptop keyboard.
My Ideal Keyboard - Narrow

For comparison, here are some other laptop keyboards. I find them all unfriendly to developers—but I am a snob.

Macbook Pro keyboard.
Macbook Pro

Wide Dell keyboard.
Dell Keyboard

Narrow Dell keyboard.
Dell Keyboard

Element Wrappers in JavaScript

Element wrappers are coming. We are going to see more frameworks using wrappers for JavaScript DOM Elements.

Sam Stephenson created the Prototype JavaScript Framework and pioneered extending native DOM Elements. For browsers that support it, Prototype extends HTMLElement.prototype. But Prototype 2.0 will not extend DOM Elements any more.

Extending DOM Elements has many negative side effects and I would say is even considered harmful. In that Ajaxian article, you can find a link to Kangax’s post that explains what is wrong with extending the DOM.

So here’s some ideas for Element wrappers that I’ve toyed around with myself. I’ll call the Element wrapper class WrappedEl.

The $ type function

You can choose any name, but in Prototype and MooTools, the $ function takes an ID or element and returns an extended Element.

  • $ is a shortcut for WrappedEl.getInstance().
  • $ accepts string IDs, html strings, DOM Elements and WrappedEl instances.
  • $ should ensure that only one wrapper is created per Element. You can store a reference to the wrapper in an expando property or in a hash of id => WrappedEl pairs.

The WrappedEl Class

This is where the magic happens.

  • WrappedEl should provide functions to manipulate every native property or function. Some examples: WrappedEl#update() to set innerHTML, WrappedEl#getAttribute() to provide a cross-browser method that mirrors HTMLElement#getAttribute(), WrappedEl#setProperty() to set properties directly.
  • Should provide a way to add methods. Would be nice if it provides a way to add methods for a certain tag. In that case it is probably best to use subclasses; e.g. WrappedEl is a parent of WrappedElTextarea. It even makes sense to add new methods by default to some tags; e.g. add a WrappedElTextarea#value() to get and set the value property of a textarea.
  • Should feel the same as DOM Element extension. If current scripts avoid using properties such as value and innerHTML the WrappedEl could even be compatible with an API that extends DOM Elements.
  • It is nice if the WrappedEl class provides generics. In other words the ability to call all the instance methods statically by passing the element as the first argument.


Once your WrappedEl is ready, you are not many lines away from adding jQuery-like API. So you might as well code it!

  • Create a collection class–called, say, WrappedElList.
  • Define a method for every WrappedEl method.
  • Chainable methods like setters should return the WrappedElList object.
  • Methods that return an HTML NodeList should return a concatenated collection of WrappedEl objects in an Array–or even better–in a WrappedElList object.
  • Some methods such as getAttribute should return the result for the first WrappedElin the collection.
  • The method to add methods to WrappedEl may even be smart enough to automatically add methods to WrappedElList.
    • I’d love to hear your ideas or suggestions in the comment section!

      Happy Wrapping!