Posts Tagged ‘open source’

That’s Great, Now Please Fix

Thursday, April 8th, 2010

Did you hear about the mouse? It’s a mouse that has no less than 18 buttons. From the press release:

“With a revolutionary and patented design featuring 18 buttons, an analog joystick, and support for as many as 52 key commands, the OOMouse is intended to provide a faster and more efficient user interface for most complex software applications than the conventional icons, pull-down menus, and hotkeys presently permit.”

This is the same logic that brought us the 5-blade razor. Somebody please smack these people with a copy of The Design of Everyday Things. Why would anybody want such a complicated thing? Beginning users will not be interested in memorizing 18 unmarked buttons. And for advanced users, ordinary keyboard shortcuts are much more effective anyway, because they will prefer to keep their fingers near the home row (the row from “asdf” to “jkl;” – touch typists are trained to put their fingers there at all times). For maximum speed, you want to move your hand away from the keyboard as little as possible.

This is even more ironic when you consider that the suite, in spite of all its open-source karma, is still full of tiny annoyances. What needs now is a focus on user-friendliness, not a mouse that looks like the console of a nuclear power-plant.

Just a tiny example. I’ve used MS Word a fair bit and I’ve learned a lot of handy keyboard shortcuts. Just try this: if you want to change the style of a paragraph, just press Ctrl + Shift + S, and start typing the name of the style you want. The same trick works with Ctrl + Shift + F for font and Ctrl + Shift + P for font size (points). If you have to do this a lot, this shortcut is a great time saver. I haven’t been able to find any equivalent shortcut in Is that the reason why we need an 18-button mouse now? Can’t we just fix the software itself?

I wonder why allowed their name to be used for such a weird project. I fear that this will only re-enforce the stereotype that open source software is never user-friendly.

The relation between Garbage bags and Databases

Friday, January 1st, 2010

In my local supermarket, you can find two brands of garbage bags: There are the “A-brand” garbage bags, and there are the “house-brand” garbage bags. Both come in rolls of 20, each bag holds 60 liters, and both come with the same convenient closing strips. There is only one difference: each roll of A-brand garbage bags costs 40 eurocents more.


Garbage bag (*)

How could this situation exist? Why on earth would you pay anything more than the cheapest possible? They’re just garbage bags, for crying out loud! They’re probably even made in the same factory.

But for some reason, be it superior marketing, brand recognition, or some persistent belief that the more expensive bags really do hold garbage in a superior fashion, there are enough yuppies who dump the expensive brand in their trolleys without thinking twice.

But at the same time, my local supermarket would be foolish to abandon the cheap brand. There are plenty of cheapskate customers who do pay attention to price, and who are really not embarrassed to be seen with a no-brand garbage bag, every Tuesday when they put the trash out, in front the whole onlooking neighborhood.

In marketing terms this is called segmentation: by catering to each market segment (cheapskates and yuppies), the supermarket can make more total profit than if they had carried either only the cheap or only the expensive brand. As always, Joel explains it best

I’m sure this is also something the marketing geniuses of Oracle know. Oracle, well known producer of the enterprise level database product of the same name, is a marketing force to be reckoned with. You can’t just go to MediaMarkt and buy a box of Oracle. No, if you want Oracle, you have to call them. They’ll send a salesrep, who will drive to your office, show slick spreadsheets during expensive lunch while back at headquarters they calculate exactly how much you’re worth, and how much you can be squeezed for site-wide Oracle licenses.

In complete contrast, Sun is not a “marketing” company. Sun is a technology company. They’re the geeks behind the scenes, who have produced a long list of innovative server technology that you never heard about, but nonetheless powers an important fraction of the internet infrastructure. The list goes on: Java, OpenOffice, OpenSolaris, ZFS, Virtualbox and interestingly, also a database product named MySQL.

In the open source community, Sun is widely recognized as a company that really “gets” it. Indeed, all of the products just mentioned are open source in different degrees (and some, like Java, to the highest degree possible: full GPL v3).

It’s the suits versus the beards all over again. And they’re up in arms, because Oracle recently acquired Sun. What a shock: in one corner, Oracle, the most closed, most expensive, commercial database system imaginable, used by all the Fortune 500, and in the other corner MySQL, the cost-free, open-source upstart that powers small shops, blogs (including the one you’re reading) and WikiPathways, and now they’re both in the hands of a single company? Somebody check the temperature in hell!

A friend asked if I would sign a petition to stop Oracle’s acquisition of Sun, and thus also MySQL. I’m not in the habit of signing e-petitions, and I won’t sign this one either. First of all because I don’t think it will make a bit of difference, but also because I think it’s premature. This acquisition does not have to be the disaster that some make it out to be.

Just as there will remain plenty of brand-susceptible bioinformatics professors who will keep claiming, Oracle is way better than MySQL, no matter what the application, or how much we have to spend, there will also remain plenty of low-budget shops that won’t be able to pay Oracle licenses, but will happily settle for MySQL’s smaller feature set.

It’s market segmentation all over again, I don’t see why Oracle won’t be able to keep MySQL open and still have a nice profitable business model. All Oracle has to do is to make the upgrade path from MySQL to Oracle a little bit easier. MySQL could be branded as entry-level Oracle, a gateway drug for newcomers in the enterprise database world.

Of course they could also easily fuck it up, but it’s not like there aren’t any competitors: there is PostgreSQL, mSQL, and of course there is always the possibility of forking MySQL itself (which many groups are doing right now). Because once the source is open, it stays that way forever.

No, I’m not worried at all. Happy New Year!

* Image licensed cc-by-sa-2.5 by M. Minderhoud. Technorati Claim code: FXEQMSTQ5VPE

Martijn’s Continuous Build System part 2

Sunday, July 19th, 2009

In part 1, I described what a continuous build system is, and what it is useful for. Now I’m going to write about another important use of the build system: testing interfaces between modules.

In a modular system, the parts evolve independently in different directions and at different speeds. This is true in programming as well as in biology. Applications with a plug-in system (plug-ins, extensions, modules and drivers are really all the same thing) can add new features while avoiding bloat, can be customized to highly specific uses without burdening the user interface for everybody, etc. In the end, every interesting program will have a need for a plug-in system of some sort.

Shackled by a stable interface

Shackled by a stable interface

In a plug-in system, you have to define an interface between the main program and the plug-ins. This interface is also called API (Application Programming Interface). It is important that this interface is well defined and doesn’t change over time. If the API unilaterally changes, all the plug-ins will stop working. So naturally, most programs strive to keep the interfaces between the program and the plug-ins stable. This is what the Cytoscape people refer to when they are talking about the “Stable Plugin API”, a holy grail that they have yet to achieve unfortunately.

For PathVisio we use an unconstrained development model where the interface between the program and plug-ins can change at any time, as needed for the improvement of the program. How is this possible?

Linux pioneered that model: they call a stable API nonsense. The interface between drivers and the kernel changes all the time. If the Linux developers think of a better, more consistent or more efficient way to interface with the drivers they go ahead and make that change.

So how is this possible? How does Linux not degrade into a stinking heap of old drivers with interface mismatches that can’t communicate with the kernel properly? The answer is simple: because Linux is completely open source, any kernel developer can update all drivers at the same time as they change the API.

This model has two consequences

  1. Linux developers are free to improve the kernel in every way they can. They do not have to keep supporting an old crufty outdated API to keep old drivers working.
  2. Drivers for Linux have to be open source, or they run the risk of getting out of date really quickly.

The fact that their hands are not tied to a stable API gives the kernel developers enormous freedom to improve their work. Compare that to Windows. Living in a closed-source world, the Windows developers are stuck, they can never improve their kernel without breaking everything. Windows developers tried to break out of this choke hold with Vista. Vista came with a fresh new driver API, different from XP. The consequence, of course, was that several months after the release of Vista people were still complaining about broken drivers.

Of course the problems with Vista did get resolved in the end, but it took a lot of time and effort. The key difference is in who updates the drivers. In the Linux world, the person who changes the API is also the person who updates the drivers. This is only possible because the drivers are open source. The Windows developers have to notify all the driver developers about the API changes. This is a huge communication burden.

Back to bioinformatics. Unfortunately, Cytoscape can’t follow the Linux model because they want to support closed-source plugins. A number of core developers of Cytoscape live in the closed source world, and are not keen to release their plug-in source code. This means that Cytoscape has to continue on its quest for that elusive Stable plugin API.

PathVisio, on the other hand, has no such tie-in. Although the PathVisio license agreement certainly permits the development of closed-source plug-ins, we strongly discourage it. PathVisio does not seek a stable plugin API. Instead, what we have is the PathVisio promise:

If you make your plug-in open source, we will update your plug-in whenever there is an API change.

And we can fulfill this promise thanks to the continuous build system. It tests interfaces between modules. It tracks modules from multiple repositories, and runs fresh tests whenever a programmer checks in new code. Even better, all modules that interact with a changed module is tested as well, so we can check that the interface between them still works. At this moment we track dozens of modules from 10 different repositories. All this testing lets us follow a development model where any interface can be changed as needed. If something breaks, the build system will tell us and we will fix it immediately.