Quality vs Quantity

I agree. Whenver I'm asked about this sort of thing, I encourage them to either (a) Go to sourceforge and look around at things that interest them, and join up as a contributor, or (b) Find out how to contribute to some common open-source tool that they would like changed/tweaked/enhanced, just a little. I mean, face it...there's not a lot of software that we don't have some small wishlist for (If only X did Y...it'd be so much easier).

Well, there's no need to wait around or bug people for a feature. Muck in. The other developers will help you help them, and you'll get more of what you want out of the package. And you'll have your name on it, which is cool for some people.

Skud, I predict that someone is going to take your words out of context and make it look like you said "only established projects allowed here". Then someone else will actually agree with that proposition, and say things like "why are you bothering writing a new operating system when you should be trying to make a better Linux?" (I kid you not, someone said that on technocrat once. In an article. I won't name the someone, but you've all heard of him.)

But I digress.

The new apprentice just wants what the rest of us want from the open source community: kudos for stuff they've written. If they don't think they're going to get that from a project, they won't bother. I can see why people were turned off Perl. Yes, the internals of Perl 5 are nasty, but I wonder if that's just a cover for saying that p5p is nasty...

Having come on to a few open source projects late and not having much experience with the project, I can think of three main barriers to entry.

• No roadmap. This is probably the most important. If a project has a roadmap (i.e. where we're planning to take this project next) and information on who to contact about each bit, then it's much easier to join a project. For example, suppose I think the Linux kernel is cool and I want to contribute in a small way. Where could I find a list of needed or requested improvements?
• No help with what's already there. Master hackers are turned off by the Perl 5 source (especially the regex engine *shudder*), but apprentices find it difficult to work their way through less arcane code. The documentation which tends not to accompany open source code doesn't help.
• Cool project hoarding. Yes, it's true: hackers, especially those who dominate a project, like doing the cool stuff themselves. Maybe just once we should let newbies have a go at some cool stuff to get them hooked?

I think that we need two things to channel new apprentices to useful work. Skud has identified one, and that's mentoring. I think the other is a directory of projects oriented towards getting people started working on real projects doing real work. List tasks by broad topic and difficulty, and put in a contact person from whom you can get more details and help on what's already there.

Pseudonym, I couldn't agree more about the importance of roadmaps.

When I recently found myself with a few weeks of spare time on my hands, I went and joined the Debian documentation mailing list, since I had a strong urge to do some docco work, was a regular debian user, and figured they would appreciate some help.

When I asked "what needs doing?" I got told to look at this page, which didn't really answer my questions at all. When I followed up with "OK, what needs doing *most*, and where do I start?" nobody seemed to be able to answer me. I couldn't even figure out who to talk to.

In the end I worked on a chapter for the sysadmin manual, posted it, received sod all feedback, and wandered off in bewilderment. I still don't know whether anyone ever took what I did and put it into CVS.

When I went looking at the GNOME documentation project I was much more impressed. There was a big table of what needs doing, how much of it's been done already, who's put their name down to do it, and who the technical contact is for each thing. Unfortunately at that point my free time dried up, otherwise I would have thrown myself at it with a vengeance.

As someone who has recently joined a larger open source project (Python), I think the "cleanness" and "understandability" of the existing code base are the deciding points. The first time I took a look at the sources I understood enough to be able to add functionality or fix bugs.

That said, I think a roadmap (or at least some sort of document stating whom to contact for what area of expertise) would be a useful thing, too. Often (e.g. with Python) this is implicit. The core developers know where the language is heading and who is an expert in which area, but making this information explicit would benefit the casual contributors immensely.

Stick a wishlist of apps on sites such as freshmeat.net, gtk.org, gnome.org etc etc. Mixture of hard ones and simple ones that should be easy, but noone has gotten around to doing it yet. In that vein attached is brain dump of my last list, last written for suggested college projects, nevertheless people in various groups could put together little lists of accessable projects that newcomers could tackle.

1. Add emf support to libwmf, add ability to write wmf files. Document the otherwise undocumented (but implemented) wmf format for fame and fortune, add as a dependency to abiword and xfig. Create windows binary with cygwin package and sell it for small fortune. Multiple interested parties possibly available on contact depending on my current mail deletion status.

2. Upgrade xswallow for mozilla era, Create (possibly with xul etc) front end for the plugin to allow users to configure it by point and drool rather than the current honestly difficult to understand configuration mechanism.

3. Create your own ultra minimum gnu tools based distribution. For each tool you add to to the distribution break it into tiny dynamic libraries (most gnu tools already are in little libs except they create static libs which are linked into the program before installation), try to identify common operations[1] and document the resulting apis, draw big graphs of the reality of code reuse through cut and paste vs libs, compare sizes before and after, execution times after you have created the minimum distribution vs a stock one. For extra credit suggest some automated techniques for achieving
   1. auto recognition of common code blocks
   2. speed ups for highly dynamically linked apps

4. Fiddle with glade to give it a "cross platform" option where it creates a single description file which can be converted into a skeleton app for gnome,kde,windows,mac, half assed web cgi driven thing etc. Do NOT implement conceptually different or missing features on platforms that do not have them, draw charts of what are the graphical concepts and features that span all four or five major interfaces. Write deep thoughts on the nature of existing cross platform graphical toolkits and their ilk. Focus on the dichotomy of cosmetic vs conceptual differences between interfaces, good to consider thought experiments of mercator (X windowing system translator into sounds for blind people)[2] etc for what I'm at here.

5. Write a folding binary editor, the readme of andy's fbe tells you what I want, its reality though is disappointing. A folding editor that can make good guesses (ala strings, unicode strings, heuristics based on user experience etc) as to where strings begin and end, guess size of structures, guess what is an offset and what is a length etc. i.e. automate the idiot part of reverse engineering.

6. Take winresdump and extend to dump window pe and ne binary menu resources etc and convert to glade format for creating speedy skeleton free clones|ports of windows applications, Probably see wine for more information

7. Implement a linux telephony solution, spend at least a month or two writing to each and every makers of hardware all the way down to whatever tech staff you might find with a vague interest in helping with specs and data for drivers, (ask alan cox, and linux kernel as well). Get supervisor to buy card from the most approachable vendor. (Update: possibly out of date now that dialogic has announced that they are doing something with linux, start with them, and see what they are at.)

8. Reverse engineer realplayer streaming audio format.

9. Create clone of purify, identify one or two classes of bug which purify can grok and implement them. Talk to gcc people for help for their side, Electric fence (bruce perens) for one such feature etc.

10. Write a APACS30 module for ccvs, ilug thread for more details

11. Extend Doc++ to output docbook. (crude starting patch available on request)

12. Crack RC4 within two weeks, (microsoft office encryption) Deep Crack hardware solution specs for the harder DES is available. Algorithm in wvDecrypt. e.g. http://www.craki.com

13. Go to www.wotsit.org and pick a format without a [l]gpled converter and write one, e.g. microsoft project format.

14. Go to software bazaar and pick a project.

    [1] e.g every configuration file reader|writer like utmp didn't originally have an api but now has etc, extrapolate this sort of work to the logical limit

    [2] Making Mercator work on something that is not its native obsolete platform is also a project. autoconf and automake Mercator, make it work under modern X. Document its status. Reap kudos from blind community.

I agree to the conclusions regarding beginners, but I miss the aspect of why experienced people might want to run their own projects, instead of joining existing ones. I have to confess, I am one of these, and I am not deeply involved in free software activities anyhow.

I am not on a mission, and I don't want to have to excuse myself for beeing in the commercial software development business, so any belief-driven or politics-driven projects are out.

My spare time is rare, and I don't want to waste it for advocacy. So any project with large controverse technical discussions is out.

I want to have fun when coding, so any project where someone is going to tell me what I should do is out.

I don't want to increase my bloud pressure, so any project where someone is telling me what I should believe and which open/free software guru I have to follow is out.

I don't want to become famous, but I also don't want to spent my energy to make others rich and famous, so any of the high-profile projects is out.

What remains? Running my own small stuff (if anything at all). It's my spare time, it's my life, it's my fun - and in the event that others might find the stuff useful, they can have it.

You have basically started the old discussion what people motivates to write free software. There is a huge list of reasons why people do it. And depending on their reasons, they join projects, or don't.

Thinking back to the kind of code I wrote when I first started out, it would have been difficult for me to have worked on any serious project and not done more harm than good. I'm confident in my abilities now, but it's been over a decade since I started seriously coding, back in the pre-internet days.

Most software projects, even those started by professionals, wind up in the bit bucket before shipping. This is honestly a reasonable defense against poor quality software. A completely failed project generally dies on it's own, without interfering with anything else.

If you're involved in an open source project and can honestly find ways newcomers can help out, then more power to you - it would be nice if more people learned how to work in groups early on. I'm just advising caution.

I am definitely an 'apprentice'. I've contributed little code to free software projects. I sometimes get enthused about a program, and think about adding a feature. Often I grab the source and find the time required to 'dive in' too high. Also, my experience with mailing patches to people hasn't been great.

The most recent example is the PGPi. It didn't compile on Compaq Tru64 UNIX so I added a build option, it worked and appeared consistent with the existing setup. I mailed them a patch, and didn't hear back from them. This just isn't encouraging. Even if my patch was wrong, it'd have been nice for them to mail me and say "Thanks, but we're not going to use it because of..."

On the other hand, in my free time I'm working on some code for GNU. Maybe it'll be useless, but maybe it'll be of use. I said I'd do it and it's taken me over six months, but I'm working on it. And the wonderful thing is that people at GNU talked to me and replied to email. They weren't `aloof' and welcomed contribution.

That's probably the most important thing - if you frustrate newbies then they'll do their own thing, or they'll become disillusioned with the 'community' idea and lose interest in writing free software.

One reason that FreeBSD doesn't support as many devices as Linux does is that FreeBSD requires that people actually finish the drivers that get committed to the tree, and those drivers that fall behind or break in the fullness of time are removed. It is the focus of the project to make sure that things are of a high enough quality to not cause support problems. We do this through code reviews on changes to the system, as well as a number of other means. Much code is rejected on the basis of it being too green or too messy, whereas in Linux the code is picked up.

Don't get me wrong, in Linux you have several drivers that have become good that were initially junk. People took the time to clean up the original as their contribution. They took the time to handle the edge cases and things are better for it. However, there are many that didn't receive this care and now likely no longer work or work poorly and never will be fixed. Sometimes this approach works, and other times it doesn't.

The key to improving quality is to force people to concentrate on it. It is to teach them how to do a better job. It is to encourage them to continue to improve their software. It may sound elitist, but in fact teaching people how the system works and how to produce high quality code raises all boats in the long run.

And isn't the Open Source movement based on the predicate that I can't do it all alone and you can't do it all alone, but together we can do something that working separately we couldn't do?

This is kind of a tangent, but this does apply to the quality of projects.

Over the weekend, I got to see the true power of perforce, and realized that there needs to be a global perforce (or some revision control system with similar features) database. This way projects like FreeBSD can say, pull binutils from GNU's tree, pull perl from perl's tree, do a p4 integrate to grab all the latest changes, merge in any conflicts, and be done with that.

This isn't limited to large projects like FreeBSD, Linux, binutils, or any of the major ones. It can also be useful for smaller projects. Say someone is using a set of library routines that exist under FreeBSD but not under Linux. You can just pull in the routines, use autoconf to comile them in if you're under Linux.

This would actually significantly help reduce the number of bad copies and increase the reliability of existing software. Programming should simply be glueing existing pieces together and never having to write YA(insert some common routines).

If you want people to work on your project rather than starting their own, you simply have to present a compelling enough body of work that they want to use. More users means more developers. That's why releasing early, releasing often and having those releases be usable is important. Utopian projects that intend to create the Perfect and Feature Complete instance of some category of app never go anywhere, because they never make releases. Modularity and minimal code interdependencies are also good, so people can maintain their own little corner of the project.

But you'll never get rid of the gHellos, just look how many people try to write their own web browsers despite seeing that IE, Opera, and Mozilla all required years of work by a large development team. Hackers are all about hubris. ;-) Most likely people writing gHello are best off playing in their own sandbox for a while until they learn more anyway...

Ultimately a few entries in each project category leads to much better software, IMO. Competition is good, and it's also good to have a backup if one project loses its primary maintainers or just makes a seriously flawed architectural decision.

Plus, where would we be if we couldn't claim to be more 37337 due to our use of the most obscure or kewl {editor, window manager, operating system}????

I think of it as a Good Thing that there is tons of immature code out there. I generally think of the open-source community as one big genetic programming engine. ;-)

When you take a look at the population of a healthy GA or GP engine, you generally want to see lots of immature material with high turnover, narrowing up up a few older, successful survivors. You don't want it to get too top-heavy; that way lies monoculture and stagnation.

You need all of that immature raw genetic material around to provide a nice broad and dense base of species diversity, so you can survive bad mutations and diebacks. Evolution is messy and inefficient, but over time it seems to be able to always beat central planning, usually in really bizarre and unexpected ways.

There are lots of possible ways to improve the quality of software out there, and a growing number of people are working on it. An obvious one is people working on Linux distributions: they notice problems in software themselves or get bugreports from users and work on them. They do (some) quality assurance tests on software as well. Of course this only holds for a small percentage of the software out there, not everything is packaged for a distribution (although Debian certainly seems to be trying :).

Anyone can contribute by quality by simply letting authors know about problems in there software or submit feature requests. They will learn from their mistakes and end up producing better software. Remember to be nice and friendly though: if you are not you will only annoy the author and nobody will benefit.

Something thing we lack is good documentation on writing good code. Take something like security conscious coding: as far as I know there is no simple text with guidelines on how to protect your code from symlink attacks, buffer and heap overflows, printf formatting issues, DoS attack, etc. A text with simple guidelines for creating user interface is something a lot of people could certainly use. I am sure people can come up with more examples here..

I don't agree that joining existing projects or finding mentors is the best way to learn how to make quality software. You learn that from personal experiences: making mistakes and correcting them. Looking at other peoples code can be insightful, but it is a solution.

From one point of view writing another Hello World, or another IRC client doesn't scratch anybody's itch: it's been done before, perfectly well, and most of the new attempts don't really add anything very much.

But building such a program can scratch the "I want to write an open source GNOME app" itch. Writing yet another ghello might teach the hacker a lot about the libraries, and the systems. That probably doesn't belong on freshmeat, but they'll get a thrill out of seeing a few people download it from their home page. It would be highly appropriate for them to put this in their advogato diary.

When they first write a useful app and it does get into freshmeat a whole new phase of learning begins: they have to look after their users, prioritize feature requests, accept patches, try and build a little community, maintain compatibility. All these paratechnical skills can evolve as the person more deeply enters the community.

Development develops developers

G. Booch once observed that what matters most in whether programmers start from scratch or leverage the efforts of others is their own perceptions. When the perceived cost of using others software exceeds the perceived benefit, programmers will avoid the activity.

The types of things you're mentioning here seem to be characteristics of larval hackers since Linux has gotten more popularity. I don't see anything wrong with letting these people reinvent the wheel and practice on their own little pet programs, if anything, it helps them get a bit of experience under their belts before they come out into the larger community and start wanting to rewrite vast tracts of code.

Newbies to any type of project like to see their contribution. They like to code new features, rather than fix bugs or do normal code maintenance. Maybe reinventing the wheel is just an exercise for them to do that.

And let's not forget that different people have different reasons for different things, and not everything is silly and going nowhere. The first idea that comes to mind is of GNOME, which was definately reinventing the wheel with regard to KDE. Don't get me wrong, they had freedom issues with KDE that they made into reasons to start over, and I myself am a GNOME user, but if reinventing the wheel or striking out on a project that SOUNDS way too ambitious should be the death penalty for a project, then we wouldn't have GNOME.

Even if all the other startup projects never become a GNOME, they're still worth having. Maybe not for you, but they're worth having. I hope the time never comes where freshmeat stops listing those, because they're a very valuable resource I think.

Maybe you should do it backwards - maybe you should go out to freshmeat and search for so called "loser" projects and find the author of "Hello, World!" in GNOME and mail him and say, "You seem to know a thing or two about GNOME programming" (whether it's true or not) "would you like to come work on my project?" People don't have to volunteer for open source projects. They can be asked to do them. They don't have to say yes of course, but there's nothing out there that says if you're maintaining a project you have to wait for people to come to you and you're not allowed to go recruit.

Maybe part of the problem is that Freshmeat makes it too easy to announce a project. Something I'd enjoy contributing to, if only someone else would set it up, is an online journal for free software projects. That is, a place where free software developers could submit articles about their projects in a scientific fashion. The articles would outline the goals of the project, algorithms that have been successful, those that have failed and so on.

This would allow new programmers to find a project that is established and clearly well though out, as well as giving the authors a place to get criticism from other programmers who might not otherwise examine their design choices.

Actually, advogato would be a good place to host such discussions. All we would need is a seperate messages page just for submitting papers about a project. Does anyone else think this is a good idea? I'd be more than willing to submit some papers to get things rolling.

Send it again, politely, and see what happens. If it's not accepted, you can always post it to the relevant forum (-users mailing list or whatever) or on your homepage. That way people who need it can find it, and it has a better chance of merging later on.

Regarding Matthew Parry's comment (mettw), I have been considering setting up a "Journal of Free Software Development" for a while.

As he says, one can imagine is a freely redistributable online journal, with a transparent web-based refereeing process similar to advogato. In terms of content, I've had in mind something like the journal "Software Practice and Experience" but for free software.

The main question I have is whether it would be desirable to create a separate journal, rather than using existing journals (Linux Journal, Journal of Linux Technology, and general journals, ACM etc) or just putting articles on your project website. Usenix used to have its own journal ("Computing Systems") along similar lines for Unix, but that ended around 1995.

I'd be interested to hear from anyone who is interested in this subject before I post a full Advogato article (click through to my personal homepage for email address).

The issue of quality vs quantity concerns me greatly as well. Thanks for posting this.

I definitely agree that there's a tension between creating a new cool project and helping out on an established one. In the latter case, the project has already developed some warts, you have to navigate a somewhat unfamiliar codebase, and the ego strokes have pretty much gone to the founder of the project.

Of course, in the former case, you end up with fifteen vector illustration tools, not one of which is really useful for getting work done, and more being created each month.

I think that plugins help resolve this tension somewhat, and have been one of the engines behind the runaway success of the Gimp. You can create a plugin from scratch, not having to worry too much about an existing code base, yet you are adding to the project as a whole.

I'm not saying this is a panacea. For one, it depends on a well-designed and stable plugin interface. Gimp has an easy time with this because pixels are much simpler than most of the things you'd want to use plugins for. Second, it's a lot harder to achieve coherence if your system is built from a smattering of plugins. Gimp has struggled with this as well. But, in general, I do think it's a reasonable approach for trying to manage more ambitious projects. I consider Nautilus to be the next big experiment in an app organized around the plugin principle. It will be quite interesting to see how it goes.

The way to get people to help improve the quality of free software is for a project to have a QA team. This helps both by people doing proper QA on it, and also it introduces people to the product so they might hack on it one day.

I didn't think I had the "31337 coding skillz" to get involved in a free software project, but I found a page on mozilla.org about getting involved in their QA organisation, so I did that. Being involved with QA let me get well acquainted with the product without being intimidated, and now I'm one of their more senior QA volunteers - I now maintain that "getting involved with QA" page :-). I am also beginning to get stuck into bug fixing of the code itself (I posted my first one-line patch this morning.)

I'm not saying that QA is a less worthy occupation than coding, I'm just pointing out that this was the way I got involved with a big project without being daunted by it.

Gerv

As you mentioned above, many newbies just want to code ANYthing, for an excuse to go on freshmeat, or just get recognized a little. Right now I am in the process of writing an MUA in Perl. I know that there are lots of MUAs (but from what I hear only one or two in Perl, so I guess that's a plus). The other MUAs out there are either written in a language I don't want to write, too advanced for me to code on, or just not what I want to do (I'm into writing programs that run quick and do the deed they're made for, without all the extra cruft).

You mentioned how someone said they don't know enough to contribute to Perl's development - this is true as well. I'm not sure how involved you are with it (you mentioned you've never looked at the source code) and comments / suggestions are great, but I would prefer to actually program it. I like writing things and watching them run. User feedback is essential to development, yes, but I want my name in the credits (if there is any ;) as a programer.

The other thing is, mostly with Perl though, TMTOWTDI. While writing my MUA I have come across many CPAN modules that do the same exact thing, only in a different way, a way that may run quicker / smaller / etc. I definitly think that there are enough IRC clients and mp3 players and whatnot, but sometimes I enjoy looking at a few different versions of the same thing, just to see where different people like to take it.