Inside the mind of the enemy: the community

Short URL: http://fsmsh.com/1890

-->

A few years back, Eric S. Raymond (or, as everyone else calls him, ESR), wrote a lengthy paper about this community. Entitled The Cathedral and the Bazaar, he wrote about how the Free/Open Source Software (FOSS) community does what it wants when it wants to.

I don't think he was entirely wrong; I just don't think he was entirely right, either.

The path less traveled is still traveled

Now, before I continue, I must mention that, although I write this article for Free Software Magazine, and there is a gulf between ESR and Richard M. Stallman (also known as RMS, the patron saint of the Church of GNU, and the head of the Free Software Foundation), this article does not exist to promote either ESR's or RMS's point of view as the correct one, or even consider them grounded in this reality.

So, two weeks ago, I wrote about how business analysts lie, cheat, and perform dime-store magic tricks to make middle- and upper-management believe in fairy tales. And don't forget the rubber chickens, either.

A friend of mine, after reading that article, said something rather interesting: he said that what I wrote was a subset of ESR's essays. I thought about it for a moment, and I realized that he was right; I really did write about a subset, especially the last sentence: "Linux goes in all directions simultaneously."

ESR effectively wrote the same thing many years ago, and helped inspire hackers everywhere. He even inspired me to hack away at software, although my wizardry skills would make even Gandalf stifle a giggle. I, like ESR, wrote about the Bazaar's modus operandi based on observations.

To state this in a non-verbose way: we seem to have come to the same conclusion on this.

The implied action scene

So, where else does the FOSS community get tripped up? If business analysts are simply the ugly hunch-backed minions of the Bad Guy then who is next on the list? IP lawyers? No. Bill Gates and his vast Olympic-sized wallet? No (although this recent Novell thing isn't helping). RMS and ESR? No.

The next bad guy on the list is us. Yup, us: the community. The FOSS community itself is its own enemy. Not the worst enemy, mind you, but an enemy that still has to be dealt with. Before, I said that Linux goes in all directions simultaneously; this is both a strength and a weakness.

As a strength, this allows any individual to hack on any feature, any program, any anything and scratch his/her proverbial itch on whatever is bothering him. In this way, we often get interesting solutions to interesting problems. The worst bugs are fixed, the most wanted features are added, and the most annoying of either are dealt with in a quick and painful hacking session that often involves swearing like a drunken pirate.

However, as a weakness, this also means that leadership in some projects is non-existant or ineffectual. In Cathedral-style projects, your not-so-friendly neighborhood PHB (fueled by the lies from various ugly hunch-backed minions), although wrong 120% of the time, says what goes in a project. The PHB's vision is corrupt; but none-the-less, it still is a vision.

Now, some Bazaar-style projects do manage to wing it fine. The Linux Kernel itself is a good example, with Linus Torvalds acting as a benevolent overlord. He allows just the right amount of free-form hacking to go into the kernel, and refuses to commit patches that don't provide 100% useful content.

Other projects, however, are glowing examples of what not to do. GNOME, sadly, is one of those projects. Backed by the Free Software Foundation and the FOSS community as a whole, the GNOME project for many years just added lots and lots of feature creep and otherwise unnamed bloat. They seem to be digging themselves out from under that, but they have a long road ahead of themselves.

The GNOME project lacked true vision for those years, and feature creep and other long term development problems rushed in to fill that hole. Problem is, many projects are just like GNOME. Incidentally, few Cathedral-style projects suffer from lack of vision: those that do simply die off and are never heard from again. Bazaar-style development allows projects to be in a zombie state for long periods of time, where it is vastly expensive for a Cathedral-style project to do the same.

Another example: for years, XFree86 languished under the control of David Dawes (who also proved earlier on that a benevolent overlord actually has to be a benevolent), and Keith Packard had to go ahead and fork XFree86 (producing X.org, the now de facto X server for most Linux distributions) to solve this issue. Not only did Dawes lack vision, he got in the way of everyone who did have vision.

The Solution?

I hate to say this, but there may be no easy solution. Unlike in the Cathedral, the Bazaar has no official leadership. Linus, as did Dawes, as do the core development team of GNOME, only have limited control over their small section of the Bazaar; and even then, it is only for a limited time.

Someday Linux will be replaced, someday X will be replaced, someday GNOME will be replaced. In the Cathedral, nothing is ever thrown away, nothing is ever replaced, but here in the Bazaar something better always comes along. This is a strength, not a weakness.

Due to the fact that there are more people like Dawes than people like Linus running projects, the only solution would be to act like the Cathedral. For short periods of time, I believe Cathedral-style development can be beneficial to the FOSS community; someone with vision (corrupt or not) would control a project, driving development behind it, and have the project reach goals in specific time frames.

The future may prove that hybrids of both styles will provide better frameworks to deal with large projects.

Category:

Comments

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

How do you think you can get OSS developers to stay in specific time frames?

The vast majority of OSS projects don't have such a large base of developers that would allow them to develop in Cathedral-style. After all, they are all doing it in their free time, and the amount of free time people spend on OSS projects needs to stay a free choice, since when it doesn't (like when setting deadlines) most developers will just jump off.

-Guenther

Patrick McFarland's picture

Okay, I haven't figured that part out. Smaller projects don't really even apply here. Larger projects /do/ have paid developers. So, I think a combination of getting paid to develop and self-discipline would help.

If anyone does figure out how to make this work well, feel free to write about it. I'll be sure to link it in a future article.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

If anyone does figure out how to make this work well, feel free to write about it. I'll be sure to link it in a future article.

Have you seen http://producingoss.com/

This is just on that subject.

regards DaveP

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I've read producing OSS several times. It's a great read.

I don't think the original article is entirely correct. He's spot on the problem but the solution isn't short-term cathedral-style leadership. The solution is growing more and better bazaar-style benevolent dictators. Books like producing OSS are a good way to start that off, but we need much more of such works.

For example, producing OSS is biased towards larger projects backed by a corporation that have a clear goal (not surprising since it draws heavily on Subversion - backed by Tigris - with the aim to replace CVS). A book similar to that but focussing more on pure community-led projects with more fuzzy goals would be a great addition.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I agree with you!

Someday Linux will be replaced, someday X will be replaced, someday GNOME will be replaced. In the Cathedral, nothing is ever thrown away, nothing is ever replaced, but here in the Bazaar something better always comes along. This is a strength, not a weakness.

This is just the nature of the community, it's the source of creativity and power

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

You don't necessarily need more resources if you used brief cathedral style releases. I agree that there may not be enough developers on a given project to sustain this long term, but as an example, if you briefly assigned a new "benevolent dictator" who *did* have the time to contribute, the same core developers would put in the same amount of time they normally would put in. They just do it against this leader's list, instead of their own. To say that F/OSS has to be freewheeling to be free, re-enforces the false notion that it's wild and unpredictable--and worse, that it's in its nature to remain so.

It doesn't have to be "I say Johnny must develop threading, and Billy must develop asynchronous I/O..." instead you could say "We need threading and asynchronous I/O" by March, Johnny and Billy may still be the main contributors, but if they can't be, it's on the "hit list" for anyone to take a whack at it. Then rather than lose the power of the collaborative devel environment, as you would in a true Cathedral where only Johnny *is allowed* to develop threading, you keep the F/OSS magic, gain the control and predictability or a Cathedral build.

Just as many closed source companies have adopted the F/OSS methodoligies within their ranks, even though the licensing is not F/OSS.

It's still a choice to participate in this or not. But don't assume that all projects are alwasy done by volunteers in their spare time. Anyone who develops knwos that it always happens in fits and starts of inspiration and work. External deadlines only add stress, and the mild notion of cohesion. You need them, for example, when you have a worldwide marketing push behind a release, and you need to know if x fature is going to be in by a certain date, or not.

Done well, you can do it with *less* resources than a pure F/OSS or pure Cathedral environment would.

This also solves the problem that all engineers are not dyed in the woll code poets. Some actually need to be given a task. In a hybrid model, those folks can chip in, without having to be super creative as well as a competent engineer.

So, in the case that Patrick puts forth, you have a mutually agreed to Cathedral-style build. I agree that you are the benevolent dictator for three months, and you say "these are the 5 things we will have by then". At the end of the three months, we either have what we agreed to or we don't. The bonus is that we don't have all the Cathedral's shareholders pissed at us if we miss the mark.

Linus is in charge of the kernel, but he hands off the stable tree to someone else (Alan Cox, Andrew Morton...) and has a core group of sub-dictators that do in fact set the agenda for those outside the core group. Another is Keith Packard's efforts in X.org, if he hadn't taken a leadership role, stating "this whole thing needs to go this other way" we'd still be watching XFree86 rot from within.

Red Hat is another example of a living in both worlds. RHAT has to have a pre-announced schedule for their paying customers. How do they ensure that these features will be in without forking? Partly by allowing the upstream developers to do their thing and packaging/marketing the output, and partly by paying folks to do the work they want done.

--jeremy

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

You don't necessarily need more resources if you used brief cathedral style releases. I agree that there may not be enough developers on a given project to sustain this long term, but as an example, if you briefly assigned a new "benevolent dictator" who *did* have the time to contribute, the same core developers would put in the same amount of time they normally would put in. They just do it against this leader's list, instead of their own. To say that F/OSS has to be freewheeling to be free, re-enforces the false notion that it's wild and unpredictable--and worse, that it's in its nature to remain so.

It doesn't have to be "I say Johnny must develop threading, and Billy must develop asynchronous I/O..." instead you could say "We need threading and asynchronous I/O" by March, Johnny and Billy may still be the main contributors, but if they can't be, it's on the "hit list" for anyone to take a whack at it. Then rather than lose the power of the collaborative devel environment, as you would in a true Cathedral where only Johnny *is allowed* to develop threading, you keep the F/OSS magic, gain the control and predictability of a Cathedral build.

Just as many closed source companies have adopted the F/OSS methodologies within their ranks, even though the licensing is not F/OSS.

It's still a choice to participate in this or not. But don't assume that all projects are always done by volunteers in their spare time, or that Cathedral bulding means all engineeers are turning in exactly 8 hours worth of code per workday. Anyone who develops knows that it always happens in fits and starts of inspiration and work. External deadlines only add stress, and the mild notion of cohesion. You need them, for example, when you have a worldwide marketing push behind a release, and you need to know if x feature is going to be in by a certain date, or not.

Done well, you can do it with *less* resources than a pure F/OSS or pure Cathedral environment would.

This also solves the problem that all engineers are not dyed in the wool code poets. Some actually need to be given a task. In a hybrid model, those folks can chip in, without having to be super creative as well as a competent engineer.

So, in the case that Patrick puts forth, you have a mutually agreed to Cathedral-style build. I agree that you are the benevolent dictator for three months, and you say "these are the 5 things we will have by then". At the end of the three months, we either have what we agreed to or we don't. The bonus is that we don't have all the Cathedral's shareholders pissed at us if we miss the mark.

Linus is in charge of the kernel, but he hands off the stable tree to someone else (Alan Cox, Andrew Morton...) and has a core group of sub-dictators that do in fact set the agenda for those outside the core group. Another example is Keith Packard's efforts in X.org, if he hadn't taken a leadership role, stating "this whole thing needs to go this other way" we'd still be watching XFree86 rot from within.

Red Hat is another example of a living in both worlds. RHAT has to have a pre-announced schedule for their paying customers. How do they ensure that these features will be in without forking? Partly by allowing the upstream developers to do their thing and packaging/marketing the output, and partly by paying folks to do the work they want done.

--jeremy

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The reason why you reached the same conclusions as ESR is because his coding skills make Gandalf stifle a giggle too.

So the simple conclusion is that both you and ESR don't really have any idea what you're talking about.

I have no idea why you're compelled to comment on this topic, given you freely admit you have no clue.

At least you're honest about that, whereas ESR portrays his clueless commentary as divine inspiration.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

its probably true. You didn't sound like you understood wtf you was talking about. ESR is a joke too- what did he make? Shitty fetchmail, gpsd?

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I just thought I'd mention that Patrick has a point and his troll, is a 13 year old newbie who just learned how to use arrays in C.

I have been programming for 10 years and I was there before GNOME or KDE came along, I can definietly back this up.

GNOME was awful for a long time, it was a horrible hack, GTK back in version 1.x didnt even have double buffering and the performance was atrocious (still is in some ways) and it's only in recent years where GNOME has a vision and a direction has any improvement been made. To me, it's the best DE you can get, it does what you want, without getting in your way and if you want to do things they didnt plan for, you can do it another way (REAL men don't mind playing with gconf, pussies whine and moan about why there isnt a button in the preferences).

KDE was the same pretty much, but KDE has consistently improved quite nicely, with or without licence issues (which don't exist anymore)

Cathedral style development can be helpful for a project, but it usually appears in one of two forms

1) from the beginning

this is where the project is created and managed from the outset in this way and never really changes, it only changes to the bazaar way of development when someone forks it and you usually find a less controlled development cycle is representant in the fork. X.org would be an example of this, but as well as being bazaar style in development, it's also kinda cathedralic, since each team that works has it's own vision and management, it depends on your point of view, look at the tiny details, you see bazaar, look at the big picture, it's usually cathedralic.

2) since yesterday

this is where someone yesterday got pissed off cause the project is going nowhere very quickly and he's got his ideas about where he wants to go and forks the project. Since he's forked the project, he's going to go in his direction and nobody is gonna stop him. (I cannot think of an example)

so, ignore the trolls, they don't know anything, they just dislike ESR because someone told them something horrible about him and they believe it, they most likely never formed their own opinion, just read someone else's.

chris

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I had thought GNOME was an alsoran because Sun got involved with the foundation (see Mozilla).

Learn something new every page.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Check the FreeBSD fork to DragonflyBSD my Matt Dillon. He was convinced the FreeBSDers were going the wrong way toward SMP. He tried to persuade them, they cancelled his commit privs (can't play nice with others) and he forked.

-crl

Patrick McFarland's picture

Maybe I wrote about the wrong thing. Inter-project politics are the enemy... in fact, I may write about this in a future article if I can enough for an article on this.

Anthony Taylor's picture

Inter-project politics are also an issue, but intra-project politics are a larger one. GNOME vs. KDE is a strawman-- there *is* no GNOME vs. KDE, except in the minds of the fanboys. (Full disclosure: I'm a GNOME fanboy, because I prefer C over C++. But I run Enlightenment as my primary desktop.)

GNOME folks really don't worry about the KDE folks, and KDE folks don't worry about the GNOME folks. Really, there's more cooperation between the two projects than most people realize.

I think the big problem isn't the lack of a regular release schedule. It's exactly what you said: a lack of focus. GNOME started out with a clear direction-- build a good application environment, the infrastructure needed to create a full desktop environment. They had great direction, and they built ORBit2 (an excellent CORBA implementation), Bonobo, the GNOME libraries on top of GTK+, and a bunch of other great stuff.

But they forgot to ask: what were they going to do with all that once they had it?

Enlightenment gave way to Sawmill, which begat Sawfish, which begat Metacity. The panel saw rewrites. The control center saw rewrites. And all the time, there was no clear direction other than the application environment itself.

I love GNOME. I think it is going in the right direction. But, I also recognize it is an evolutionary process, in which many ideas are floated, but only a few survive. They aren't necessarily the best ideas, but the are the best for the current environment.

I think this is a good thing.

I think many people misapprehend the significance of the free software development processes. Like evolution, many paths are tread at once, creating a complex environment. If one or many turn out to be evolutionary dead-ends, it isn't a big dea, because there are other ideas that have survived. And, unlike evolution, we can scavange the good parts of the failed ideas for our own use. (We can scavange the good parts of the successful ideas, too.)

Closed-shop development processes are not that fortunate. MS-Windows doesn't stand a chance. Not because GNU/Linux is better (for any arbitrary definition of "better"), but because, for all its user-base size, MS-Windows an isolated environment. Some ideas are lifted from other projects, and Microsoft is trying hard to make the transfer of ideas one-way (check out the recent "look-and-feel" licensing announcement for the MS-Office 2007 GUI for an example). But, it is essentially a sealed environment, forced to march lock-step with Microsoft's marketing agenda.

Anyway.

Intra- and inter-project politics are often seen as a bad thing, but I disagree. I think they are part of the environment. Without environmental pressures, evolution would not take place, as there would be no selection process. Politics are just one (very important) selection mechanism. It isn't the best one, but it doesn't have to be the best to exert a positive pressure. For instance, it helps ensure the people working on a project are compatible, with agreeable goals and personalities.

We don't need schedules, because we don't need to conform to business processes. We don't need regular release cycles, because all steps forward are not uniform in size or complexity. Even Microsoft realizes this, which is why MS-Windows Vista is so late. We don't need pre-defined management structures, because people are different, and projects are different, and it's probably better in the long run to let the management of a project form organically around the people and the project itself.

That doesn't mean we should stop thinking about project structure, or structured releases, or other management issues. It means that free software project leaders should probably learn people skills, and management skills, and nunchuk skills, and horse riding skills, and computer hacking skills.

Or maybe not.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I'd suggest taking a look at Mark Shuttleworth and Canonical if you are looking for a "Cathedra-zaar" approach to FOSS.

Patrick McFarland's picture

Except Mark and friends don't exactly develop software in the usual way. Most of their contributions are simply improvements, not exactly the whole entire application from the ground up kind of thing I was looking for.

That said, its close enough to use as a future example.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I think that the special thing about Ubuntu is that it is developed in a kind of hybrid "Bazaar Cathedral". It's as bizarre and creative of an idea as code names such as "Dapper Drake". A well-dressed duck is quite a progression from the carbuncular wild pig of "Hoary Hedgehog".

At any rate...

One of the most interesting cathedrals in the world is Notre Damme à Chartres. From what I understand it was quite the community project. For example, there was an entire guild dedicated solely to hauling water up the hill from the river. Have you ever heard of a "software cathedral" memorializing such a utilitarian job as water hauling to the scale of an entire stained glass window, visible to all after just walking in?

Community is the material out of which change comes. Also, it the the community which actually causes the change. Can any truly large project be completed by a single man or committee? The community is important even to the "cathedral" model of software development. A team (or sub-team) must function as a community for the Product to exist as a coherent whole. It is imperative that software cohere for two reasons. First, incoherent software is incoherent to its users, thus isn't useful. Code which is incoherent to the limit doesn't compile. Code which meets the minimum requirements for the language may compile, but doesn't run well. Perhaps I am biased, but it seems to me that the vast majority of software is designed to actually be executed, and as such I'd like to limit the scope of my definition of software to *runnable* software. Perhaps someone exists who writes a kind of post-modern "program" which is only useful as a poster, or wallpaper, or something...

Back to Ubuntu though:
It seems as if Mr. Shuttleworth is the architect. I think that it's interesting that the fiscal patron of the "Bazaar Cathedral" is named Canonical. The Ubuntu project is divided into guilds which anyone can join. One could say that the Ubuntu Cathedral is being built out of raw materials provided by the entire GPL software topos. Debian can be seen as the bazaar where tier two materials are purchased (pre-made glass, already quarried rock, etc.); after this, the Ubuntu project dyes, carves, polishes, etc. the Debian goods. I'd write more, but this is getting kind of long. Basically, I think that the Ubuntu project isn't really a "new thing"...it's an application of a time-tested model. Mind you, though most GPL programmers work for free, they're definitely not serfs!

Something cannot be created out of nothing. If easily workable source material can be had for free (as in beer, and freedom...), then one ought to both complete the job quicker by utilizing it, and honor the work of the original author by showing everyone that his or her work is worth using.

Hmm, this is worth keeping. I've archived my post here:
http://members.shaw.ca/nick.steeves/pensees/a_bazaar_cathedral.html

Nick Steeves

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I think this was the road Novell was starting to travel until the ugly hunch-backed bean counters got their hands in it.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The Open Source Applications Foundation is an open-source cathedral.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The premise of this article seems to be that the bazaar style of development in the FOSS world is a potential danger to the survival of the FOSS community. Your anecdotal proof is that in the cathedral style of development, projects that don't produce profitable applications die off quickly to be replaced by "better" applications (which is a very questionable assertion).

But then you go on to use the XFree project and its fork, X.org, as further proof, when in fact, I conclude exactly the opposite. XFree was usable for a long time. The project team had disagreements about its management structure and so the code was forked, and the new team is now moving forward on tasks that were stalled before. In a cathedral (read proprietary) environment, the team would have had to start from scratch (to maintain the metaphor--buy new land and materials, hire architects and contractors, etc.). In the bazaar (FOSS community), hardly a step was missed.

The description of the Gnome project is supported by the fact that the project team performed a major overhaul on the code for version 2. But I disagree that it supports the assertion that the FOSS community is its own (less than worst ;~) enemy. All that can be said about it is that if a FOSS project team decides its code needs a major overhaul, then it can, and often will, do exactly that. Whether that is good or not depends on how much you have invested in applications that also have to be overhauled for the new version.

I believe that you have overstated the case against the bazaar methodology. It is true that the bazaar style of development is less ordered (some would say messier). But the process works overall, as the many high quality FOSS applications prove. And the many other advantages that go with the system--such as a low barrier to entry, longevity of successful projects, transparency, etc--are strong arguments in favor of supporting the system as is.

Patrick McFarland's picture

... although I didn't mean to. GNOME's redirection was a Cathedral choice in that the heads of the team had to (basically) enforce this choice; "No more crap in the tree until the rest of this crap gets shoveled out," in essence.

Keithp's choice to fork was more of a Hybrid choice, because it was lower in the chain of the command Cathedral isn't the right description for it. Dawes decided to screw over XFree86 over ego/political issues, and Keithp forked and ran his project in a hybrid style for a short time.

The Cathedral/Bazaar metaphor falls apart in situations like this. The tech industry is dominated by businesses who have small yet powerful development teams: no inter-office politics, no stupid PHBs, no metric tons of bullshit. Some of the best commercial software has been written in environments like this; coincidently, thats the closest similar work-flow I can find.

Also, I wasn't exactly making a case against Bazaar, more of a case that this isn't a black and white thing. With new-GNOME and X.org as examples, hybrids do seem to work well for short periods of time; it just happens that Bazaar and 'False Prophet' (ie, anti-Linus) is what screwed them up in the first place.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I find it much more likely to read ESR's essay as a condemnation of the GNU project's development style.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I tend to agree with some of what the author has stated in his article. I have worked with a number of other UNIX operating systems and find working with Linux to be fustrating in the very least. On IRIX, Solaris or Unicos/MP I can count on in an emergency situation certain pieces of software always being configured in a certain way because they are core parts of the operating system. Linux all bets are off as each distro has its "own way" of doing low level important functions. In a mixed enviroment datacenter this can become somewhat of a challenge.

Instead of reinventing the wheel hundreds and hundreds of times why not really innovate? In some cases I'm almost certain that the "development" that the OSS community does is just moving around files and recofiguring things out of political need rather than functional need.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Your comment is ridiculous, because each "Linux distribution" is in fact a separate operating system; RedHat and Debian may share a kernel and substantial quantities of other code but they are different systems and you cannot expect them to work identically, just as you don't expect IRIX and Solaris to work identically even though they are both Unix.

I suggest that there is someone in your organisation who doesn't understand this and they are to blame for your mixed environement data center challenge, not the Free Software community or "Linux".

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

if you compare unices at all, rhel is the only distro with a linux kernel, that you're able to trust. not, because redhat is doing a "better" gnu/linux, no, they just keep working things and innovate in things like the redhat-cluster-suite or extreme improvements over nfs, etc.
short question: how much different device models were used and trashed since the linux kernel 2.4 ?

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The Bazaar works particularly well for project that are composed of unix style small tools. A grammar is setup initially, everyone builds all kinds of little tools searching the space that can be put together, and the useless parts drop out. The problem for gnome, kde, openoffice, is that big graphical "environments" aren't really modular in the same way, that say apache can be. They can't have small interfaces; they've got to be these big object interfaces with big objects that hook everything together constantly, so that the end-user doesn't need to understand the toolkit. The pattern has been clear for a decade: build a project where the user's are experts, and you can break it into small interfaces, and depend on your users to put it together: apache, the kernel, shells, programming languages. Try to put it in one black box so that naive users who don't want to learn a toolkit, and instead want an interface, and the bazaar approach is painfully slow, as the entire structure has to be adapted to the space search.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

like it did mine: people blame YOU for problems in FOSS software, since there is no company to blame. You'll get instance experts combing through the source code and criticizing every line and every decision you made. They can't do that if you use Microsoft.

Do a complete code audit on any open source tool you plan to run, if you can't/don't have time, don't install it because at some point someone is going to find something ugly in the code and blame you for it, and use it to destroy your career so that they can get ahead.

Commercial code is safer, because you CAN'T look at the source, no one expects you to, and they and you can blame the vendor for bugs and holes.

Remember, most people want to blame someone for problems (we have a cultural/biological fixation with blame), there will be problems with software (b/c it is all pretty much junk, OS and COS), and if there is no company/vendor to blame, someone at sometime (probably soon)is going to blame YOU.

I've been amazed and flabbergasted myself at how prickly some open source coders can be, people who's job was created by the decision to use OS at a place turn around will turn around and attack the people who made OS happen at an place, and because it's open source, they can...

Terry Hancock's picture

Sounds like you had a really bad experience, but I've never encountered any kind of trouble like that. I suppose it depends on the organization.

Any organization that spends more time on assigning blame than on solving the problems is going to be a terrible place to work, no matter what software you use, though.

Of course, these are all reasons why I have gravitated to being self-employed or working in very small organizations, where the politics are easier to manage.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

How is there no company to blame? If you install RedHat AS, you can blame RedHat. If you install Ubuntu, you can blame Canonical.

If you choose to install Gentoo, then of course there's no company providing support (that I'm aware of), and you are where the buck stops.

If you make the decision to install any software, proprietary or Free, then you have to live with consequences of your decision, it's not the fault of the software, the developers or the community... you sound like a teenager, "it's not fair, I didn't do it". If it wasn't your decision to install whatever piece of unsupported software ruined your career, then it was your place to defend yourself appropriately. It's no-one else's fault that you were unable to do so.

Terry Hancock's picture

It's more like it gets recycled. Things get worked into new projects.

I'm not sure that Linux will ever be "replaced", though I have a strong feeling that it will evolve into something that will no longer be recognizable as the thing we call "Linux" today (perhaps every single line of code will be new, but it won't have happened in one ‘replacement event’, but rather over the course of time).

Free software permits this kind of organic growth, whereas proprietary software development is in isolated bursts. Proprietary software developers spend a lot of time ‘re-inventing the wheel’, because they can't just grab code from the pool to start with. Even when a free software project dies, it still leaves a body of code which some similar project may opt to plunder for ideas if not actual lines of code. It's rare to start a project and not find some piece of it already written for you. Sometimes you re-write it anyway, but you have an original idea to work from.

You don't really engineer free software the way you do a proprietary project. Instead, you plant a seed, and encourage it to grow.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

This article is very true and many open source developers should listen.

What I have noticed is that the only OSS projects that actually have succeeded have a corporate style of management (most are now backed by large corporations).

I think it's just human nature. When you have a ton of people moving in a bunch of different directions, the project suffers. You need a few people to keep the vision going and cut through all of the BS/code that should not be added to the main base.

If you take a look at sourceforge and freshmeat, you can see a countless number of failed projects that do not follow these practices.

----------------------------------------
High Performance PHP
http://www.jaslabs.com
----------------------------------------

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The whole strength of FOSS is it's disoraganisation: progress is Darwinian. This may seem inefficient, but it ensures we don't all charge off the same cliff like lemmings. Leaders lead only for as long as they do so well. If they are poor leaders, and the project is not useful, it dies (though useful parts of the code are likely to be picked up). If the project is useful, a better leader takes developers with him in a fork.

The fact is that there are no shortage of poorly led projects in the commercial world, with just as much wastage.
Vista anyone? And what happened to the WFS that was supposed to underpin it?
BTW, what did happen to Duke Nukem Forever?

Need I go on? I can if you like.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Your examples of why Free Software can be bad are in fact examples of why it's so good. So GNOME is having trouble? That's why we have competition in the form of KDE. XFree86 trapped by obstructionists? The XOrg fork soon solved that problem. RMS and the FSF have themselves been on the receiving end of this "Free Software Justice"--look at the glibc/libc business, GCC vs EGCS, and Emacs vs XEmacs. At least they learned their lesson from some of those instances. Similarly, Linus Torvalds remains head of the Linux kernel project only as long as he maintains his credibility among the community: if he ever tries to pull a David Dawes, the kernel will fork, faster than you can say "BSD".

Lawrence D'Oliveiro

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

At least *someone* said what I was thinking the whole time! The FOSS community has proven more than once that it is able to handle crazy idiots and jumping neurotics. The latest example of this healthy self-regulation is the cdrtools/cdrkit fork. Kudos to Debian, to hell with you disbelievers! ;-)

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

By Theo...

Bazar like in a Cathedral..... In fact. i really dislike using Linux for the same reasons outlined in the article. It's a hack. There is little consistancy, undiciplined and it's a project management nightmare. While it hold true evolutionary development, it truly lacks guidance under poor leadership. The community needs this. While some some of Linux works, other parts just blow up dismally. Ever try to install a USB printer?

The OpenBSD model is a nice balance. Theo has imposed a working philosophy, and has found like minded people who agree and work together. I like how all modern daemons are re-written now to follow a strict code audit and also a working admin approach. OBSD is organized to be consistant and workable. It just works.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Excellent article. You might find one that I wrote, which has been widely read and circulated (I think something like 100,000 downloads to date) to be interesting and relevant, as it takes an in-depth look, and perhaps answers, the core question you raise here. Well, OK, I don't have an answer, but rather a way to predict which FOSS projects will stay focussed and which will wander and fade. Anyway, I hope you'll check it out:

http://www.moonviewscientific.com/essays/software_lifecycle.htm

Craig James
cjames (at the domain) moonviewscientific (with a dot) com

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

...that is what Red Hat, Ubuntu, Mandriva and Suse where for... Suse in one hand did a great job with versions 9 and 10, but then they made that deal with Microsoft! Come on Suse, drop Microsoft, there is still hope for you!

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Patrick McFarland needs to get some things right.

Richard M. Stallman (also known as RMS, the patron saint of the Church of GNU

GNU isn't the church, is Emacs. More specifically, St. Ignucius of the Church of Emacs

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

In no particular order:

Not learning from mistakes. For example: if you've used/developed for X-Windows and other window systems, you know that X is fundamentally broken in many places ("a good idea for the 80’s, and still is"). But the OSS community keeps going back to it, while professional developers laugh and avoid it like the plague (it should have been an EX-Windows 15 years odd ago). Sometimes, things are so fundamentally flawed that they should be thrown out. If you don't throw the mistakes out, new developers assume that they're being used because they're good, then they repeat the mistakes.

Not understanding your customers. Do customers want ease of use, or do they want lots and lots of features? Do they want reliability, or a RUBY interface? Until OSS developers learn how to write software for someone other than themselves, OSS is not going to see widespread adoption outside of it's current audience (which happens to equal the developers). If customers tell you that they need something, and you don't understand it -- work with them until you do understand it. If you compare yourself to a commercial software package and users laugh – you might not understand the software or the users well enough to make that comparison (and have a lot of coding left to do).

Not enforcing standards. I'm not talking ISO here, just coding practices. Things like "crashes should never be allowed to happen", which implies things like checking all error return values, checking for bad pointers, using something other than the C assert function (which just crashes the app), using C++ exceptions correctly, etc. Or "everywhere there is text, it must handle Unicode correctly" (kind of essential for handling languages other than your own). Or the old file format rule of "write strict, read permissive". A lot of these should be common sense. But many of the inexperienced developers working on OSS don't know this stuff. And it shows in the final result.

Reinventing the wheel. Hey, do I have to explain this one? I mean, have you looked at a list of SourceForge projects lately?

Assuming that if it's good enough for your thesis, it's good enough for everyone else. It never is. Too many OSS projects start this way and never get better. Proof of concept code is maybe 5 to 10 percent of what it takes to make shippable code.

Lack of testing. Ok, in theory everyone using your software is testing it. But are they all trained to find, reproduce, and document bugs? Are they going to report the bugs at all? And if they do, will they really give you what you need to reproduce the bug and fix it? Sometimes this can be solved by adding unit tests. And sometimes you need a partner to sit down and find every edge case that you missed, and every OS bug that you need to work around (or report!). And how many OSS projects have been tested against other applications and other projects? Just because your code can read the file you wrote doesn't mean that everyone else's code can read it (too much incestuous testing, not enough free love testing).

Thinking that OSS is inherently better just because it's OSS. Sorry, but you've got to get over yourself. Just because it's free and 800 highschool kids contributed to it does not make it better. Of course, the reverse is true - but commercial software that sucks doesn't last long (without a monopoly and massive marketing engine behind it, of course). Unfortunately, OSS software that sucks keeps getting updated, then branches, then updated for new OS releases, then branched again, a few features added, then 20 similar projects start up (after that, see the first paragraph) and everyone involved goes to slashdot and whines about it.

"I invented it, so it must be the best". Yeah, and there's nobody on the planet smarter than you or with a bigger, um, idea than you. This is a frustratingly common pattern in the OSS world.