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.

Recent comments

23 Apr 2000 13:04 Avatar 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.


23 Apr 2000 01:25 Avatar shwag

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

22 Apr 2000 23:02 Avatar 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..............

22 Apr 2000 20:47 Avatar 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 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.


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.