Articles / The Importance of Non-Devel...

The Importance of Non-Developer Supporters in Free Software

Jacob Moorman of the Marble Horse Free Software Group writes: "With the increase in size of many new and long-term Free Software development projects, it is important to recognize the crucial value non-developers may hold in advancing the efforts of these projects." They may stand outside the spotlight on the project. They may not invest time in writing code. Whether they are on the listed staff of a project or not, project supporters who do not contribute code still play a crucial role in the day-to-day perception, acceptance, and strength of most Free Software projects. The people most frequently recognized in conjunction with a project are the administrative staff (maintainer or lead developer) and the developers who contribute the largest portions or most important portions to the code base for the project. What of the others?

Developers usually test their changes prior to submitting them for inclusion in the project, though the time it takes to do a complete evaluation of these changes is enormous. Many projects have official test staff, people who download the latest project materials and invest a considerable amount of time validating software functionality and bug fixes. Other projects have unofficial test staff, people who seem to live for new releases, downloading them as soon as they become available. The reports of testing staff help make a Free Software project smoother, generating a higher quality final product and reducing the amount of time developers need to spend doing things other than writing code.

General project supporters come in many flavors. Some aid in the propagation of the software, assisting in large implementations of the software or installfests, or providing inexpensive physical media (such as CDs) containing the software. Others provide themselves as a support resource for the product, helping new users with the installation or implementation of the software, responding to concerns on mailing lists, and providing direct support via IRC for other end-users. Project supporters play an important role which reduces the amount of time developers and administrators need to invest in support, the foundation of all good projects.

Why are testing staff and general project supporters not often recognized for their efforts? In some cases, it is because the administration of a project is unaware of their efforts; people providing unofficial assistance do not always make their efforts known to the administration. In other cases, it is because developers and administrative staff may not understand the importance of these volunteers; they may ask more questions of the developers at times, but certainly reduce the overall question load.

It is my belief that administrative staff of Free Software projects should seek out information on people helping to support their efforts. These details should be showcased, not tucked away behind the scenes. Granted, some project supporters may not want to be in the spotlight, but I suspect most would not feel adversely about receiving due recognition.

On a few development projects, there is one other class which is often overlooked in correspondence, the end-user. It is important that every end-user receive a response to her question, even if the answer is one stating that the software is not yet ready for public consumption. To ignore the comments of end-users, the issues they most frequently report during installation or use, or requests for assistance, is to abandon the best interests of your project. Without end-users and general support staff, who does your project help and who would be there to support them on a day-to-day basis?

To those who already make effort in recognizing those who support their projects, I applaud. For those not already making effort to recognize excellence in non-developers, I propose some basic things you can do to encourage this type of behavior. First, post a Web page containing the names of those you wish to recognize for their efforts. Even if they stop these efforts in the future, leave their names on the recognition list; consider this an honor roll. Second, consider including them in project decisions you feel may affect them or may be of interest to them. Finally, give them verbal encouragement for their efforts; people who are thanked for their efforts are much more likely to continue in this capacity.

With the growth of Free Software worldwide, we must increase awareness of how people may help these projects and recognize those who already support our efforts. Most of our greatest supporters know no programming languages.

Jacob Moorman is the Project Lead (and an active developer) for the Marble Horse Free Software Group (though by day, he currently works as a Systems Programmer/Analyst for a healthcare-related corporation). In conjunction with the Marble Horse Free Software Group, he supports the use and development of a wide variety of Free Software solutions in programming, documentation, and advocacy.

T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let know what you'd like to write about.

RSS Recent comments

22 Apr 2000 08:38 residentgeek

Say, that's me!
* r_g feels important now

Seriously, though, even though I'm no developer, I try to get new releases of
cool software as soon as they're out, and contribute to the wishlist ;-) w3m
and licq are my current pets (not to forget mozilla).

22 Apr 2000 13:51 waldoj

Hard To Contribute
I think one of the problems is that many open-source projects feel impenetrable to those of us that are not already 'inside' the development. As a less-than-mediocre C programmer, and an intolerable Perl programmer, I don't feel that I can make contributions in this respect. (But, hey, when it comes to PHP I can be pretty useful!)

Normally, to jump on the bandwagon, one would grab the latest distribution, make some fixes, and send 'em in. (I guess. Like I said, I don't know *how* to get involved.)

But when it comes to other ways to help, like testing, writing docs, support, etc., that's even *harder* to get involved with. There's no logical first step, like with fixing up code.

I hardly expect for a CVS Support program to pop up, but it would be good for most coordinators of open source projects to provide an in-road for those of us that would like to contribute in non-traditional manners.

22 Apr 2000 15:53 drfrog

tell 'em how it is
developers need the support of non-developers
willing to put in the time to make support docs,q&a,
& general feedback on what should be included
in the project

22 Apr 2000 17:19 keithsogge

Documentation for KDE and others

If you check out KDE's home page you'll see that they are looking for people to help their documentation projects. (Go to the News area) People looking for a way to help out might want to check it out.

There are other ways to help as well. I've written some crossword puzzles to be included with the program krossword, Other games have level editors to create new levels such as kgoldrunner. Of course those are just games, but they're a good place to start.

22 Apr 2000 17:51 Avatar learfox

...and the connection between...

I've capt'ned various projects for WolfPack, and often
I find myself as a the lead developer. I agree that most
recognition (sterotypically or deserved) goes to the
major contributors and those with the most responsibility.

However it is my own experiance as a QA'er and beta tester
of many other projects (most notibly GIMP in the early days), that the connection between the big names and those who help smooth out the edges is exceedingly poor.

A lot of project's big names do not take the time to
converse with their audiance. This is not reffering to
being too busy but viewing such help/assistance/opinions as unimportant.

This in my experiance is the number one problem- nothing hinders a project more than the relationships between the top's and the audiance being disconnected. And yes...
WolfPack puts this relationship at the number one spot on its priority list, right next to complete and reliable documentation.

22 Apr 2000 20:47 hmcdonal

The more visibility, and the more feedback, the better for
any OpenSource project. This is particularly true for such
low-priority tasks as reference documentation, user guides,
FAQ's, and on-line help. Web-based tools where users can
add questions and answers to a FAQ are very helpful, and
encourage wide participation, which makes the FAQ much more
helpful. Reviews and comparisons of sites and of tools is
an easy way to encourage wider use of good ideas.

22 Apr 2000 23:02 rpage

The DXR2 Project is a perfect example of working with end-users
As a member of the creative labs open source dxr2 mailing list I have always found that 'they' (the mover's and shaker's' on the list) are always receptive to commentary. '
They (and many others) always respond very quickly, and indeed the list is a tribute to open-source - ie. newbies are responded to very quickly, and many problems are solved for newbies without a hint of sarcasm or scorn.

Feel free to flame.

It's going to /dev/null anyway..............

23 Apr 2000 01:25 shwag

well said
well put. very good article. brought tears to my eyes and made me raise my flag in the air!

23 Apr 2000 13:04 wolffe

Non-developer support
There comes a time when all good programs will come to the mainstream...but in order to do so, and gain acceptance, the end-users (like myself) have to be able to navigate their way through the setup of the program, with as few problems as possible. When problems do arise, a quick and helpful email from the developer(s) will go a lot farther than someone whose only response is RTFM.

Although I have no practical programming experience, I do know my experimentation and learning of the Linux operating system has brought me in contact with a few program developers through their support email-lists...and on more than one occaision, suggestions I have made seem to have been incorporated (at least to some limited degree).

Not looking for recognition on a website or other documentation; just want to help with an opinion of what might be nice and helpful with a program that I have found to be easy to use, fast and friendly to the system, and has great potential. When more end-users get involved, the programmers understand what is being looked at in their application, and they can respond to produce an even better product...or explain to the users why it wouldn't work.



Project Spotlight


An ecological niche modeling framework.


Project Spotlight

Diladele Web Safety

A Web filtering ICAP server for the Squid proxy server.