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.
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:
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.
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.
For comparison, here are some other laptop keyboards. I find them all unfriendly to developers—but I am a snob.
Macbook Pro keyboard.
Wide Dell keyboard.
Narrow Dell keyboard.
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
$ 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
$ accepts string IDs, html strings, DOM Elements and
$ 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.
This is where the magic happens.
WrappedEl should provide functions to manipulate every native property or function. Some examples:
WrappedEl#update() to set
WrappedEl#getAttribute() to provide a cross-browser method that mirrors
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
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.
WrappedEl is ready, you are not many lines away from adding jQuery-like API. So you might as well code it!