Free Software Helping Your Community

So, we all talk quite a bit about the ethics of Free Software.  We talk about its practical benefits, its social benefits, its economic benefits, and its ethical benefits.  Let me ask you, when’s the last time you went out and actually tried to help someone use it locally?  Yeah, I know that we’ve got millions of Free Software users around the world, etc, etc.  Are you helping locally as well?  Those folks who are bringing Edubuntu to their local schools, and those French folks who’re bringing Kubuntu to their Parlaiment, they’re role models for us.  They’re doing something not only by developing, but by working with people to help society tap into the benefits that are there.

I’m not talking about advocacy here, either.  I’m talking about getting out of your home and office and going to help someone set up and use Free Software… today.  Your local library, your local schools, your local government, the freakin’ boy scouts.  If we really believe in social benefit and helping our neighbors, then let’s go out and help our neighbors.  Let’s run for local office, let’s make dynamic web sites for libraries, let’s set up Edubuntu labs in schools.  And let’s share our work with others.

Hacking For All GUIs for Fun and Profit

This may come as a surprise to some, but there are several Graphical User Interfaces (GUIs) and desktop environments out there. The most commonly known ones are:

  • GNOME
  • KDE
  • Xfce
  • WindowMaker
  • Blackbox
  • Enlightenment
  • FVWM
  • IceWM

Most of these programs (desktop environments and window managers are still just programs, or more commonly collections of programs) perform very similar tasks like putting window decorations (title bars, close/maximize/minimize buttons) on the windows, controlling focus with the various windows, moving and resizing the windows, maximizing windows, minimizing or iconifying windows, and of course closing windows. To some it is surprising that there are so many choices in desktop environments and window managers, but like in everything else it’s usually a matter of preference.

The primary difference between a window manager and a desktop environment is in the scope of its functionality.  A window manager tends to let the other programs that are not part of the window manager itself perform the  general application functionality while it maintains the more core window manager functionality. Desktop environments, on the other hand, tend to provide users with a smoother and more integrated interface with a suite of programs to do things like manage network connectivity, control settings and themes, search for files on the machine, manage persistent states between sessions, and then some—like KDE and GNOME—even go so far as to have a very well integrated set of applications that perform general tasks such as word processing, editing text files, and chatting online.  Desktop environments also tend to have a window manager program included in their suite, though often times it is possible to substitute another window manager for the one included in the suite.

Some prefer to have a desktop environment, some prefer to just have a window manager, some prefer to mix and match. The bottom line on that is that different people like to run their desktops different ways, and with such a long line of window managers and desktop environments to choose from, people are more free to run their machines the way they want to instead of being limited to only what developers put into any single package. This freedom enhances productivity—except in cases where people toy around with their desktop environments and window managers excessively—and allows people to really configure their desktop to work for them instead of them having to conform to the desktop. It also allows those who want to experiment with different usability patterns to try coming up with interfaces that are better geared for specific audiences such as children, students, senior citizens, or those who are unfamiliar with general-purpose computing.

All this to say that it’s good that we have choice, so we should focus on supporting those choices and trying to use these choices to enhance software freedom in general instead of only sticking to the interfaces that we ourselves have adopted and grown to enjoy.

Like many things in the world today, GUIs can be a very polarizing factor. There are many who adopt a single GUI and then write off the rest by citing specific things they disliked about the GUI. Just because we don’t like feature X in GUI Y, or we think GUI Y may be more bloated than window manager Z, doesn’t mean that some other person couldn’t find that GUI or window manager perfectly usable and even preferable to the one that we ourselves use.

So how does this make us better programmers?  When we focus on what the users would want rather than what we feel like coding, then we are engaging a project in a way that can really benefit our community and could be more useful in general. Also, when you’re coding for multiple GUIs you will sometimes find that different paradigms present different benefits and different challenges than others. Qt4 has begun to use a model-view architecture for their GUIs, while GTK is much less structured. Also, Qt and GTK both have GUI tools to help build the interface while wxwidgets and TK are still much more manual. The more we work with, the more diverse ideas we’re exposed to, and the more user experiences we’re able to witness. Taking more ideas into account we can find ways to make better software for ourselves and our user community.

A distribution that enables more user choice while also keeping applications well-integrated is one that a user will be able to adapt to much quicker. If a user has been using Ubuntu’s GNOME for three months and then decides to try Kubuntu’s KDE then the entire distribution will feel better for that user if they don’t have to completely transition to new programs and interfaces for everything. That’s not to say that one should water down their interfaces or program collections, but that there is a need for common functionality between the environments even though the interfaces may differ.

This enriches Free Software by keeping up with user freedom. The more free a user is to choose their interface, the more they will understand that they really are free to use their computer how they want to and that they are not limited to what a proprietary software vendor has chosen for them.

One of the oldest problems when it comes to maintaining GUI software has been that sometimes the business logic of an application gets so tied into the interface of the application that it is difficult to change either the interface or the business logic without impacting the other. This also makes maintaining the application and upgrading to new library versions very difficult. Sometimes separating the back-end from the front-end can be tricky, especially when the line between front-end and back-end can be blurry. To determine whether an bit of functionality is front-end or back-end, ask yourself three questions:

  1. Is this functionality something that the user is directly interfacing with? If the functionality is anything other than directly taking an order from the user (e.g. handling a button click or mouse event) or directly displaying information to the user (e.g. printing output onto the screen or updating a status bar or presenting direct audio feedback), then the answer to this question is “no” and this functionality should be part of the back-end. If the answer is “yes” then this functionality should be part of the front-end.
  2. Is this functionality something that we could take the interface off of? If the functionality is some sort of data processing like saving a file or transmitting data, or if the functionality is not directly tied to the user then the answer to this question is “yes” and it is part of the back-end. If the answer to this question is “no” then this functionality should be part of the front-end.
  3. Could I break this functionality down any more than I already have? This question should always be asked so that we’re not sticking too much of anything in either the front-end or the back-end.

Now, we all know that the open desktop folks work super hard to give us all guidance on desktop application development. It’s normal that we’d all want to stick to their standards—or rebel against them depending on our personalities—but it is important to remember that when you’re developing a front-end to blend in with a specific environment to actually attempt to adhere to the standards and conventions of that environment. GNOME and KDE both have UI guidelines that are distinct and very well followed, and it is advisable to adhere to those guidelines to make your application work better in that environment… but not to the point of kluge. It’s okay that KDE and GNOME look different, and even if we prefer one over the other it is okay for us to adopt the look of the one we’re targeting in our development.

The point of this whole document is, of course, to say when you have to choose between developing for GNOME or developing for KDE, choose both. It’ll make your application more usable, and it’ll make you a better hacker.