There are really two bazaars that fire the boilers for free software: one dominated by talented amateurs who create for love; the other, by professionals who create for money. This creates a curious bi-modal nature to the free software/open source community: there's always a certain amount of tension between the schedule-driven bottom-line interest of commercial entities like Novell, Red Hat, or even Canonical and individual hobbyist developers. I think it's fair to say that the “soul” of the movement belongs to the hobbyists, even though free software needs commercial interests to achieve what most people think of as “success”.
There are people coming into the movement from both sides: some are amateur programmers (like myself), who got interested in programming for fun, and see free software as a useful form of “leverage” to get more done for less effort. We see the copyleft principle as a tool to turn what work we put into free software into more and bigger outcomes for our own pet projects. It's all about maximizing our amateur production for our own interests.
Then there are commercial software producers, who, seeing the success of open source packages, figured they could find a way to turn that to their advantage. We like to talk about them more, because, after all, that's where the money is. This is where we start talking about “business models” like “selling services” or “selling packaging” or trading on “use value” by using free software skills to enhance our other lines of business.
There's no hard line, of course. I consider myself an amateur programmer, but it is true that I have been paid to program in a limited context: specifically scientific data reduction software and numerical analysis and system administration scripting. I do like those areas to an extent, but they aren't necessarily my favorite thing to program. On my own, I've developed a small range of web applications in Zope to manage my own websites, and I've done some work on a game engine written in Python.
I may not be the best example of amateur production, since not much of the stuff I'm working on is finished (interestingly, the things I have finished are image-processing scripts I created originally as fixtures for my big projects: VarImage is a simple flexible on-the-fly scaling tool for images used in Zope (except it avoids doing the work “on-the-fly” as much as possible by using smart caching tricks). It models an image as a directory, and filenames within that directory correspond to a micro-language of image processing that can be done on images. Naturally, this could be abused, but after a few iterations and contributions from other developers, it seems pretty functional to me, and the obvious denial-of-service attack routes are cut off. I routinely use this as the standard image type on my websites, which makes it totally unnecessary to spend time offline figuring out how to crop images.
Likewise, BuildImage, which is not quite so mature, but still interesting, came about because I wanted to find an automatic way to create the huge number of image resources that I need for buttons, icons, and other widgets I needed in web application design. Furthermore, I wanted to be able to change my mind later on, and be able to propagate changes through my build as easily as I would change a piece of program functionality. In other words, I wanted a build system for my image resources. This requires some special considerations that make isn't really designed for: the applications you run are less cooperative about batch-processing (most graphics are designed interactively in GUI programs) and demand more dependencies, and typically you want to create many images in a single file, then dice up that file to make many images that the program will actually load (you may also want to stuff those images together into larger “skin” images). My BuildImage/XMMS tutorial shows an example of this kind of problem.
Both of these programs originally came about because I just needed to make a technical problem go away, and it occured to me that other people might be able to use them as well. And if there was any interest, I might get patches back to make them better. This worked extremely well for VarImage, which when originally released had a severe bug that meant it wasn't actually working the way I thought it was at all (Ack! The weird thing was that it appeared to work in functional tests). But then, in addition to fixing bugs, I got several new effects plugins for it, and additional cache optimizations that have made it quite efficient. Somewhere along the line, I also got motivated to build in referrer blocking, which was nice, because I was getting some major bandwidth theft on one of my sites, and the blocking really reduces that (yes, a smart person can defeat referrer blocking, but most transgressions of this type are casual).
My big projects: the Narya project incubator and the Light Princess game are not so successful. I keep coming back to work on them a bit at a time, but I never seem to be able to spend the time they really need. Nor are they really in a good state to support collaboration. These are probably areas where my amateurish project management skills are showing. Or maybe they just reflect the normal, unfinished nature of most hobby projects. It could be that I just bit off more than I could chew: most projects have to reach a certain critical level of development before people will contribute to them. And, for amateur-initiated projects like mine, that usually means one person is going to have to achieve that initial development level. Team initiation tends to be a lot less successful in free software, unless they have some other kind of unification (such as all working for the same employer, who supports them in their endeavor, at least morally, if not financially).
A little browsing on SourceForge, though, shows me that I shouldn't feel ashamed of this state of affairs. There are thousands upon thousands of free software projects, and I think it's fair to say that most of them are pretty inactive, most of them are hobby projects started by one or two people, and most of them aren't really showing signs of breaking away from that.
It'll also show that many of these projects are the most innovative and daring. Currently, I'm working on a side project for the Light Princess project, figuring out how to fully internationalize an interactive fiction engine (specifically, PUB), which as far as I know, has never been attempted. It sounds a bit too much like the natural language translation problem, though it turns out to be a bit easier than that. But it's a pretty ambitious project. And if I had to do it on a deadline, I'd probably be, well, more “dead” than “line”.
Then there are the big commercial players: people like Zope Corporation (and Jim Fulton, if you want a human to point to), Red Hat, and Sun Microsystems who've seen the advantages of free software development, and have a viable way to cash in on it. They are a whole different breed. Most of their developers are genuine pros who know their way around the programming language, the particulars of software engineering, and the editors, version control systems, and collaboration tools they get paid to use every day.
I do not envy those folks, though I do admire them. They're fun to watch in action, and many of them are far more talented at programming than I will ever be. Because for them, programming is their life.
Most of those projects aren't really groundbreaking new ideas. Many are based on existing proprietary functionality. But they are often hard problems, made so by the sheer scale of the projects. We like to imagine that anything can be built in the incrementalist approach of free software bazaars, but the truth is that some projects really are dauntingly complex. This is especially true when we start dealing with advanced data manipulation tool applications and especially computer graphics. Such projects bring in the kind of highly interdependent design that makes software engineering tough.
Also, the pros can be irritating to amateurs, simply because of their wake: they raise the standards that people expect on free software projects; they have high expectations of your knowledge about those same tools; and they have an astonishingly aggressive motivation to keep changing things that you are depending on.
So, for example, I was very frustrated when I tried to find out more about the “interface” model in PyProtocols from its author, Philip Eby, only to find out that he considers interfaces passé and something called “generic functions” are his current passion. Sigh. I just don't have the time to keep up with these guys!
Nevertheless, I am very conscious of the huge contribution that commercial interests have added to the free software landscape. Many projects that started out as hobbies have gone commercial, leading to huge steps forward in their design. Other projects are freed proprietary software (like Zope, Mozilla,OpenOffice, or Blender) that have brought in large-scale functionality that would've been very hard to get to the critical stage in the the one hobbyist programmer approach.
I think the most wonderful thing about free software licenses is that they allow these two groups of people, with their two, largely complementary styles, to cooperate. I do think it's important to realize that there are really two modes of production going on, and that the sense of pacing and the needs of each group are quite different. Some of us are working on “Navajo Time” as it's called in Arizona (“it'll get done, when it gets done”), while others are busy “punching the clock” and meeting deadlines. I'm not sure we'll ever really see eye-to-eye, but it's important to realize that both approaches have their value.