22:21 UTC

add comment

freshmeat's Stance on "Trivial" Software
by Nathan Hurst, in freshmeat - Sat, Jan 20th 2001 23:59 UTC

Every day, dozens of hackers send us news of their code and hope for a spot in the appindex. Since we know how much our approval can mean, it honestly does hurt us more than it hurts you when we have to frown over a submission and write back, "You know, this really doesn't fit here..." In today's editorial, Nathan Hurst, part of freshmeat's Australian crew, explains what goes through our minds and why we sometimes feel we just have to say "no". In the course of reading, editing, and approving the endless stream of freshmeat that passes our way, we have to reject quite a lot of scripts, small C programs, and PHP classes. While these are clearly useful to someone, we often have the difficult task of rejecting them on the grounds of triviality. In this editorial, I am going to attempt to explain what metric we use for making this decision, some thoughts on what might be done in the future to reduce the need for such screening, and, finally, what to do if your script is rejected.

Every freshmeat submission bin warrior quakes at the thought of that one submission each day that sits on the edge between clearly in and clearly out. Sometimes it's a script for automating the ripping of an audio CD; sometimes it's a PHP class to display the current date in Roman numerals.

The reason for this fear is not retribution from the offended contributor (although my spam rate increased dramatically after rejecting one person's script for bulk emailing), but rather the fact that we feel that we're sending the message "You are not worthy of contributing to freshmeat, and, by association, not worthy of contributing to Free Software". This is probably the worst aspect of the job. Sometimes it's a 10-year-old who has written his first Python program, and sometimes it's a seasoned business programmer who has had her first try at Web programming. In any case, we are going to hurt their feelings by rejecting their work.

How do we decide what is trivial?

Well, there are 3 categories of triviality that programs tend to fall into:

1. It does something that's obvious to a programmer who knows the language.

A BASH script which performs a command on each of the files in a directory might seem useful to someone who has just learned BASH, but any seasoned BASHer would have no hesitation in writing

# for i in /usr/*
# do
#   command $i
# done

directly on the commandline. Another common example of this is a PHP script that formats numbers.

2. It reimplements an existing tool without any convincing advantage.

A C program which is equivalent to tr, while an interesting exercise, shouldn't go on freshmeat unless it can do something that tr doesn't or outperforms tr by a significant margin. The older an existing tool is, the harder it is to accept a new version. In this case, we first ask authors if they can clearly explain the advantages and that they try to merge their enhancements into the existing code. We only accept the code if they have made an effort to try merging or can give convincing reasons for the two to remain separated.

Remember: the reason for this is not that we are tainted by the power of the delete button (well, usually not) and not because we are anti-freedom of speech (or software or furniture porn), but because the cost of introducing a new tool in the place of a well-loved one is very high. Just think of the cost of having to learn to use less after using more for many years. Unless there is a significant advantage to the new tool, it won't be used.

3. It proves a point but doesn't provide a use.

This category includes programs which attack a specific version of a program (which really belongs on bugtraq) and programs written in obscure languages without an advantage over existing programs (this is related to the previous point; a program written in another language which outperforms an existing tool might be reasonable).

We have received numerous exploits for programs such as Sendmail, Apache, and wuftp. Once a security hole has been identified, these programs should be sent first to the author, and then to bugtraq (if the author doesn't provide a fix in a reasonable time). freshmeat is about constructive code, not destructive code.

Occasionally, we get programs which can be reformulated into a much smaller program in a more appropriate language. One such example might be a 300-line C program which is functionally equivalent to a 10-line Perl program. Again, unless there is an advantage, we would consider this too trivial. Some good advantages include small memory footprint (not requiring an interpreter), significantly higher performance, ease of maintenance, or guaranteed realtime execution.

What should be done

In the future, there should be no reason for the editors to reject software, instead letting the community decide. To do this, there needs to be some work done on more powerful expression of software's capability, on better distributed merit assessment, and on improving the search engine.

Some work has been done in academic circles on program classification, but automated classification is probably AI-complete (and hence just as subjective as the existing system). Another approach would be to select trustworthy leaders for categories of software to write comparative reviews about programs' strengths and weaknesses and provide that information along with searches.

Distributed merit assessment could be performed in a style similar to Advogato, but the number of dimensions of specialty would require significant changes. While Advogato measures "guruness", a software repository would require, for example, "PHP guruness" or "serial programming guruness", and there are an infinity of skills between any such categories.

scoop is putting a lot of work into freshmeat's search engine, and recent changes have certainly been a big improvement (especially boolean operators and license exclusion), but an experienced Free Software user will still have to read around to find the right questions to ask to find software. Perhaps a Q and A forum for software solutions might work.

Although editors rejecting software is perhaps not an ideal solution to this problem, it is the best solution we have come up with. If we allowed all software to enter the database, freshmeat would quickly fill up with troll software (there to elicit a response rather than fill a need), once-off programs (that were written for a job and should have been left there), and script kiddie noise that would make searching for useful tools well nigh impossible.

If your program gets rejected as too trivial, don't despair. Often, it is a matter of rewriting the description and homepage more precisely, and sometimes it is a matter of distilling the problem you are trying to solve and writing a more general solution. In other cases, you may find that your code can be combined with existing code to produce a better program for everyone, or that an existing tool fills your own task better than your original code.

Besides being half the graveyard shift operator for freshmeat, Nathan is a PhD candidate researching constraint system applications at Monash University (Australia). His other main interests are mathematics, gardening, photography, and computer-environment interfaces. He enjoys playing piano with his small jazz band, Desafinado. His homepage is at http://www.csse.monash.edu.au/~njh/ and he can be contacted at njh@freshmeat.net .

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 jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Comments

[»] Is not a trivial thing useful ?
by MA Razzaque Rupom - May 16th 2006 02:22:23

My "SQL Parsing" class has been declined today. The reason sent to me was its size/complexity..blah blah blah. I would like to tell that it may be simple but useful. It's light weight but it can easily parse and execute a file containing series of mySQL statements dumped by other programs.phpMyadin has such feature but developers those need some light-weight automated system to parse and execute mySQL statements dynamically for their applications could be helpful from this. I like to get a feedback from FM regarding this recline.

--
MA Razzaque Rupom Moderator, phpResource Group http://groups.yahoo.com/group/phpresource/ Blog: http://www.rupom.info