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.
--------------------------------------------
RESULT ABSTRACT
--------------------------------------------
* 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:
OPEN SOURCE ATTRACTS USERS - A PROBLEM.
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.
USERS DON'T READ DOCUMENTATION - DEVELOPERS DO.
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.
SUPPORT EATS UP TIME.
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.
------------------------------------------------
SOLUTIONS
------------------------------------------------
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.
BE HONEST - NOW!
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.
SEPARATE USERS AND DEVELOPERS - NOW!
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.
FIND A SUPPORT PERSON - NOW!
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.
LEARN FROM YOUR USERS - NOW!
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 :-)
ENHANCE YOUR SITE - NOW!
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
|
