About Us
 Mailing List


20.02.2002 First feedback

Here's the first speaker's feedback about Fosdem 2002.

Jan Wildeboer sent us his impressions about Fosdem 2002 ... here's what he think about it.

This report sums up what happened during the discussion "Did you read the FAQ?". It should be published on the FOSDEM site if possible.

Sunday, 17. February 2002, 14-15, H1301.

About 70-80 people attended the discussion.


* Open Source used to attract developers
* Now it attracts users with no development skills
* Support eats up time, but it can be minimized
* Good solution: Separate developers and User areas
* Take all reactions serious
* Learn from your users
* Enhance your site

Contact: jan.wildeboer@gmx.de


The first question I asked was how many OS-developers were in the audience. 20 hands rise. Then I asked how many of them were project managers/leaders. 20 hands rise. My final question was how many were in charge of organizing support. 20 hands rise.

First conclusion: The most small to medium sized Open Source projects are run by a very small group of people doing almost everything.

The discussion started with me showing some experiences from the project I am involveed in, osCommerce - Open Source E-Commerce Solutions, http://www.oscommerce.com.

I asked the audience about their experiences and after a long and interesting discussion we agreed on the following problems:


In the past, Open Source projects were aimed at developers. A programmer would start a site about his project and try to attract developers that are willing to develop for the project. So the main focus was to define what you wanted to reach, provide documented sources, offer support to answer specific questions. This model is still used by most Open Source projects.

But things have changed. Due to media coverage of the Open Source/Free Software movement, more and more users without development skills are entering the Open Source world. Their expectations are something like: "These programmers do what I need for free. I can download a stable application that works and is bug free. If a need a new feature, I just ask and wait a few days."

These expectations are far away from reality. The developer ofcourse wants to produce such a solution, but he is looking for developers to help him. Suddenly he is confronted with users whining around that "this project is crap, you are not willing to help, I will tell everyone to keep away from here."

A developer that is interested takes a look at the forums/mailing lists, spots these kind of discussions and will decide to not join this project.

It also means that the developers that are actively working on the project spend a lot of time answering the same questions over and over again.

One of the project leaders in the discussion told us that after four years of hard work he and the other developers decided to stop the project and start again, but not in public. So the result was that he closed his community.

There is no easy way out, we all agreed. Many of the developers in the audience asnwer seemingly dumb questions in a rude way to stop the questioning. We all know that is not the best way ofcourse.


The user downloads a package, looks for a setup routine, installs it and starts asking questions.

The developer reads the documentation, downloads a package, reads the INSTALL, README, TODO and CHANGELOG files and works his way through.

Almost every project faces the Newbie-Questions-Problem. But telling them over and over again to read the FAQ doesn't seem to help. Offering long installation guides doesn't seem to help.


All of the project managers in the discussion agreed that support forums/mailing lists cost a lot of time. Time you would rather invest on programming.

Users tend to think that support is always offered in real-time. And when their question isn't answered in, say, 60 minutes - they start complaining. Sometimes questions are ignored because they are so obvious (from the developers perspective) that answering them will only cost time with nothing to gain. The user thinks "Nobody likes me" and starts complaining again.


As we have seen, the audience for Open Source/Free Software has changed dramatically in the past few years.

We (as developers) have to face these facts.

The media should reflect this fact and make sure that Open Source is presented the right way.


Don't promis the first-time visitor that he has found the homepage of THE solution and tell 4 pages down that all is Beta and considered buggy. Tell upfront what state your project is in, if it can be used out-of-the-box or not, list the requirements upfront and define the intended audience.


Change the design of your site and make sure that the first-time visitor is in the user section of your project. Give him the information he needs. Again: Don't promise too much! Be honest. When your project has some nifty requirements - define them upfront.


Take a look at the mailing lists and try to spot a person that started as user, now knows the project better (but he/she doesn't have to be developer) and ask him/her if he/she is willing to become the support person. Use this person to filter the newbie/users questions making you gain time for development.


Read all mailing list/forum entries whenever possible. Adjust the architecture of your project to the users expectations. Newbies can be a wealth of inspiration. Take all reactions serious. If people ask really stupid questions, ask yourself why. Maybe you should be more clear about your project. And don't forget: Newbies can be very thankful. Make it your good thing of the day to help a newbie :-)


A good thing suggested by the audience: Add full-text search to the entry page for forums. So that whenever someone wants to file a bug-report or forum message it shows some results of the search BEFORE the posting is submitted. Maybe some of the results will answer the question right away. The KDE-bug reporter uses this feature.


It was a great discussion. I am sure we all have learned from eachother. I will continue to work a bit in this area and I hope that a similar discussion can be part of the next FOSDEM.

Jan Wildeboer