Friday, October 26, 2007

Embarrassment

Why is it embarrassing that KDE is airing it's dirty laundry over khtml/Webkit?

This situation has festered for 5 years now. If no one was angry, upset, no one called anyone names, if there was no hard feelings, I think it would be time to look for another project. Dead people don't feel.

One of the first Digests I produced documented a rather messy saga in KMail. The only thing that prevented fistfights in that instance was two oceans of separation. It would be nice to say that everything turned out in the end, but that would be too simple. Development stagnated until a new generation of developers got interested. However I will suggest however that KDEPIM's solid and mature leadership was forged partly from that saga. Leadership that has maintained the KDE tradition of underselling and overdelivering, of incremental and well thought out progress. This current mess contains many lessons; what is important, what motivates/demotivates developers, who to listen to, who not to listen to. I believe that situations very similar to this one will arise again. How can anyone know how to handle the next time if the issues are not discussed?

Oddly enough, it always comes back to code. Thankfully it comes back to the code. What makes free software so good and so interesting isn't that users decide. It is because developers write what they want. If I wanted a platform where users decide I could go with 98% of the market. I doubt that many free software developers would willingly give up control that they have painfully wrested from MBA's and Marketing. Thankfully those endeavors are on the fringes in free software.


Wednesday, October 10, 2007

The Beatings Will Stop When Morale Improves

Or, The Care and Feeding of your Free Software Developer

The coming release of KDE4 will invariably ruin us all and cause paroxysms of angst among the faithful, and there possibly will be a few things not quite working as we want. It's time to remember how we can be the best user community in free software.

I am working with a piece of free software, no a whole suite of free software that I didn't pay a cent for. It arrives well endowed, with numerous surprising and delightful flourishes. And it was free. Where did it come from? Well, a bunch of computer programmers, hackers, got together by some means to write the thing. It is a result of years worth of coding, mostly done for nothing except the satisfaction of being part of something amazing. It is fun writing code. Especially when everyone else is there for the same reason.

So I as a user, without the skills to actually do things to make it work better, want this process to continue. I want a Better KDE (tm). I recognize my self-interest in this matter. I need to find a way to feed these strange people so they do more. How can I motivate these hackers so that they work even longer hours, or even better, motivate new hackers to give their time and skill to ME!

What do those who contribute to free software need? Let us make a list.

Money. Unfortunately, software hackers, like most of us have gotten into the habit of eating and wanting to sleep in a warm dry bed. Usually this takes money. How does this work with free software? Many of the core developers in KDE work for companies that benefit from KDE. The distributions sell their product. Trolltech sells developer licenses for closed development. Some developers have consulting firms that sell products. If we purchase from these firms, we benefit our beloved KDE.

A second obvious way to make sure developers have the money they need is to offer it directly to them. A case in point. KPrinter is somewhat in flux because the developer that wrote most of it is off working somewhere else. What that means is that we as a community have lost a valuable worker because someone else pays them more. Maybe we as a user community have the gained the reputation of being too cheap to keep our core assets. Hmmm. Something to think about.

Appreciation. Many who contribute don't expect or want renumeration. We all thrive when we are appreciated. Have you personally thanked the developers who wrote the software that you are using right now? If not, why not? There are many ways to get this message to them. This is the easiest and cheapest way of feeding your developers.

Keep your trap shut. This may be a bit counter intuitive to many, but may be one of the most important contributions you can make. Let me explain. Any time we use a tool we run into frustrating situations. It may not work the way you want. Frustration is one of the signs of new learning. This is normal, and I would say healthy. So what do we do with it? Do we vent our frustration on the writers of the code, who for the most part give it to us? The answer is no. If we have a dog, what would happen if we kicked it every time it came to us? It would stop coming. Same with developers. If every time we felt frustration we vented, maybe the developer would lose motivation to do anything for us.

Contributing back. We really show that we value the gift we have by contributing our skills and time to the project. Did we find a bug? File a report, and more importantly, follow up on the bug. Maybe the developer can't reproduce it. Maybe (s)he needs more information. You can measurably help the project by following up on the sometimes onerous task of tracking down a bug. KDE is open to contribution on many fronts. Translation. Testing. Packaging. Web design. Support in irc channels. Actual code contributions. etc. The project has gotten as far as it has because willing people have jumped in to contribute where they have seen a need.

And now for a personal note. I wrote the Commit-Digest for around 3 years. It was enjoyable and challenging, and I believe helped attract developers to the community. Every week someone I didn't know sent me a note saying how much they appreciated my work. Someone, I don't know who, paid the registration fees on the domain name. I didn't do it for money, or fame. I wanted to advance KDE in some way. I know my work was appreciated, and I thank everyone who made me feel that way. I wish one thing only. That everyone who contributes to KDE gets that same feeling of appreciation that I did. If they do KDE will continue to improve.


Tuesday, October 09, 2007

My Name is Derek and I'm a Usabilaphobe

An interesting post on usability at humanized.com. Including the usual slag at KDE for having too many configuration choices.

Oddly enough, software held as examples of usability are python, emacs and Firefox.

This confirms my suspicions about 'usability'. It is a matter of preference. What I like and what the author likes are different. One set of applications, programming languages, desktop environments feel natural and comfortable to me. Another set feels comfortable to him. Maybe I'll call myself an expert and say that my preferences are the most human and natural, and studies prove it again and again :)

Yes there are good reasons to establish discipline in this matter. KDE developers probably don't need to, for example, design the main menu system in their app. There are common patterns that fit most apps, with some additions for specific function. Having common dialogs, some thought as to layout and common usage patterns is helpful. Probably the best way of doing this is technological, ie. having classes that are subclassed and extended if necessary. The HIG then becomes part of the codebase, allowing developers to focus on the particular usefulness of their app.

But lets get real here. The free desktop isn't going to all of a sudden get massive user uptake if we restructure our menus and dialogs. Even if it is perfectly done. If user interface was the key, Windows wouldn't have the massive market share, OSX would probably be seen all over the place. But that isn't the case.

There is a pattern I've seen happen over the years of using computers. Someone comes up with an idea, implements it. It reflects the developer(s) with the idea. I think like that, or rather they think like me, and it shows. I find their interfaces natural extensions of the function. The software succeeds, gains a following. Success breeds a desire to go after a larger market. The product is changed to attract new users, made 'easier to use'. The product doesn't catch on in the larger marketplace, which is already occupied with 'easy to use', lowest common denominator type products. Eventually it dies, and disappears. This has happened so many times, it is so predictable, so disheartening. Why does it happen?

Very simply that the developers ignore what brought users in the first place. Why do people use KDE? Probably because they like the way the interface works, they are attracted by certain applications in KDE. Possibly because as hackers they appreciate the underlying technology, ie. IPC mechanisms, the abstraction in ioslaves, the configurability on an individual and wider scale. I'm sure that I'm not the only one who sees great potential in KDE as a development platform. Maybe I'd like html rendering in my app without shelling out to a browser. Maybe I could use a nice full featured editor part within my application. etc. Then I look at the underlying Qt libraries, see the depth of features and elegance of implementation.

And, a well rounded set of applications that I can set up for less technically inclined users.

The biggest challenge for the free desktop isn't going to be attracting users. This is already happening. Note Ballmer's screed. The only reason he is saying this is because Microsoft is seeing bad sales numbers. Vista has so far been a dud. I don't remember, well, maybe except for Windows ME, users downgrading as they are from Vista to Xp. The free desktop market share is growing. The challenge will be in attracting developers.

And what does this have to do with usability? I propose that making usability a primary focus drives developers away. It absorbs energy and focus when, lets be real here, in most areas of free software the biggest problem with usability is either lack of features or lack of stability. Again lets be real. Software is an iterative process in all aspects, including usability. Having a chorus of 'usability experts' doesn't help the software get done. Nor is restructuring a working development community to fit some goal of usability worth the risk.

I suggest that KDE continue doing what it does best. Produce elegant API's, which allow for elegant and powerful apps. KDE should continue to embrace choice, with multiple implementations competing for interest and developers. KDE should continue to be open to new developers, allowing them to grow in skill and influence. KDE should continue to aim to be powerful and full featured. KDE should remember who pays the bills, who writes the software, who contributes, and value their contribution.

Let someone else be the most 'usable' desktop, and aim to be the most useful, powerful, elegant and full featured desktop.


This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]