Thomas Baumgart gave an interview to Dave Yeats of Texas Tech University in Lubbock, TX via ICQ who is working on a dissertation about open source projects. The following is their conversation which we wanted to share with the rest of you.


Dave> As you know, I'm working on a project that looks at open-source developers and their attitudes toward users and usability. While it's not necessary you look at it, many of the questions I'll ask are follow-up questions based on the results of a survey I conducted. The results are available here: http://english.ttu.edu/Survey/ResultsOverview.asp?SID=ROHUOIRYNME4N3C

I also analyzed the bug-tracking commentary, listserv archives, and developer blogs for the Evince project in the calendar year 2005.

One thing I noticed from my analysis is that there seems to be a real distinction between what I call "normal" users and developer-users (or "source-aware" users). What, do you think, are the essential differences between typical computer users and source-aware users as they relate to the open-source community?

Thomas> The typical computer user just uses software to get his/her work done. In case of problems, they usually complain with somebody. The source-aware user in the same scenario might want to dive into the code and try to figure out what the problem is. At least he is willing/capable to assist the developers in finding what the problem is. This way, he actually becomes part of the project even though he is not actively working on it.

Dave> I get the sense that "typical" users are less welcome. Is that true?

Thomas> Not in my eyes. I don't differentiate in terms of the KMyMoney open source project. They are all welcome, even though the level of information we (the developers) have to give them when we discuss issues with them differs from the level we use among developers (source-aware). This starts with simple instructions. As an example we might say 'The file is a gzip-ed XML file' and the source-aware developer knows how to extract the information. The 'normal' user will receive exact commands from us to extract it. As I said, I don't differentiate. The only users I don't like are the one's that only say "It's crap and it doesn't work" but are not willing to help us in finding the problem. This is a different species.

Dave> Do you find that "typical" users have been willing to provide the kind of information you need to solve problems? (And, by problems, do you normally only mean bugs, or feature requests/enhancements?)

Thomas> Yes, and if they don't in the first round, we start asking them for the information we need. Sometimes, they write up something (either bug or wish) which we don't understand. Then we start asking what exactly they mean. In most cases, we understand what they mean.

Also, in the international environment we work in as open source developers there's a language barrier. Most people speak/write English pretty well, but sometimes it gets confusing. Nevertheless, we accept their wishes as well.

Dave> Do you think that KMyMoney is typical of open-source projects in the way it treats non-source-aware users?

Thomas> Well, tough question, because I don't follow too many other open source projects as active developer. I think, that the majority of our users are non-source-aware user since we have an application that is good for everybody. This differs in projects that deals with developer tools etc.  We do have some power users who look at the code but the number is rather small (my estimate). I don't know, if our treatment of the non-source-aware user group is typical or rather above average.

Dave> Because your target user is non-source-aware, do you do anything special to address usability issues? (Testing, etc?)

Thomas> One of the things we do is listen carefully to what people say. Of course - in our case - we get compared to the big players in our field (Quicken/MS-Money just to name a few). This does not mean, that we follow each wish and copy the functionality found in other applications. We do have a rough roadmap available on the web-site and we try to follow it. If there's a request for some functionality that is easy to implement, we just do it. That is, what differentiates open-source from commercial work. There, it's not that easy to just add functions w/o violating contracts etc.

There are two important things in our development work: consistency and robustness. Consistency is sometimes a wish as we also build up on existing code. The influence of some developers has led to different ways of doing things. Robustness on the other hand is very important to us. We do have a set of 230+ unit test cases which helps in this respect. Whenever we find a problem in the core component, we write a unit test case that shows the problem and then fix it so that the test case does not fail anymore.

Especially with finances, people expect a thorough and robust application, because they might base decisions on the data supplied by our project. Imagine we tell someone he has enough assets to buy a house, he does so ending up in a mess of liabilities because our figures where off by a factor of 1000 or so.

We also do have a project handbook avail. on the web-site where we explain how we develop the project. This has the simple effect, that new developers can jump right in, and for those who are working on the project already for some time to recheck in case they forget. I look up things in there every once in a while even though I am the author of most of the chapters.

Before we released the last stable version 0.8, we had a blocking issue which was called documentation. We wanted to have a robust application, but also some documentation of the application for the normal user. Most of the doc is too techy which is not a problem for me, but could be one for the non-source-aware user. Nevertheless, we found out, that there are still some areas in the user docs that need improvement.

Dave> (reading...)

Thomas> Should I press the send button more often in long answers?

Dave> No, long answers are OK. It'll keep me from interrupting your train of thought.

Thomas> Ok, looking forward to next question.

Dave> Changing the subject a little: In my survey, I asked developers to rank some motivational factors for working on software. The two factors ranked the highest were "self-satisfaction" and "doing the right thing." Why do you develop open-source software?

Thomas> Oh, we have answered this question many times ... wait, I'll see if I can find it ... Here we go: http://www.downloadsquad.com/2005/08/09/a-brief-chat-with-the-kmymoney-team/

I'd say, that one of the factors in the KMyMoney team is the "we give back something to the community" reason. I use a lot of open source programs in my daily work and some of the tools I use would have to be written. So open source makes my life easier.

There has been a discussion among the KMyMoney developers about the acceptance of donations from users. The broad opinion of the developers was "we don't need donations". We all do this development as a hobby - which sometimes just takes too much time - but it's fun. If it won't be fun anymore, I guess we all would stop to work on the project.

Dave> Going back to something you said earlier: You said you include easy-to-implement functionality even if it isn't on your roadmap. What would it take for a user to convince you to add functionality that isn't easy?

Thomas> It would have to attract a developer to do it. The attraction could either be technically challenging or rewarding. Of course, there's always the need for some functionality that the developer seeks himself. Like me looking for the HBCI integration so that I can finally do online banking. Eventually we'll get there.

Dave> A lot of open-source developers say that "the cool thing about open source is that you can change the application/add functionality (if you have the technical ability) or you can pay someone to change the application/add functionality (if you don't have the technical ability). Have you ever heard of someone being paid to develop open source for someone who really wanted some functionality added to a program?

Thomas> Yes, it's the author of the HBCI library I want to integrate. Here's the (currently almost empty) list: http://www.aqbanking.de/main.html#opentasks If a user wants a functionality, he can pay Martin and he takes the assignment with higher priority.

Dave> Does getting paid to develop open source change the "volunteer" attitude in your community?

Thomas> No, I don't think so. Of course, it all depends on the circumstances. It could be a win-win situation for all: the user, the developer and the project. It would still allow all others to work voluntarily.

Dave> Very good. Listen, I've taken up a lot of your time, and I really appreciate it. You have given me some great insight into how your project works and its relationship with users. I was browsing the KMyMoney screenshots on the sourceforge page, and they look great. It looks like you have a great application there. Unless you have any questions for me, I'll let you get back to your work.

Thomas> Which would be getting ready for bed ;) Just one question: would you mind if I share the contents of the interview with the other folks around in the project on our web-site? For that reason, do you have another link to your work other than the results of the survey?

Dave> Feel free to share our conversation with others. Right now, I don't have any of my work in a publicly available format because it's still work-in-progress. I'd be happy to send you a copy of my work after it's completed, though. It may be that my dissertation is available online somewhere once I've turned it in.

Thomas> That would be very welcome. Just feel free to send me e-mails.

Dave> Thanks again, Thomas. You've been a great help to me. I'll be in touch.

Thomas> You're welcome. It was a pleasure. Hope I did not make too many mistakes while using the English language :)

Dave> Your English is better than a lot of the university students I teach! And, for them, English is their native language! Take care and goodnight.

Thomas> CU - and of course good luck with your work