Blont of the day: My favorite FOSS development fallacy
December 5th, 2007“Project X is duplicating Project Y. X should be dropped so that resources/developers would be focused on Y” (or vice-versa).
I can’t say how many times I’ve heard this kind of argument, clothed in so many different words. At first it was a bit amusing. But as time passed, it got old really, really fast. IMHO, this line of thinking reveals a slight misunderstanding of how development on free software/open source software happens. Let me enumerate my reasons why such a logic is faulty.
1. It doesn’t always work. Not even if it has worked once, or more than once, on some other FOSS projects. Each project is unique. It almost has a distinctive personality. Just as you can’t always make two people stay together, you can’t always merge two projects and expect to have the same positive results. Although the counter-argument to this is that it may. But the point is that there’s no certainty really.
2. You can’t force people to stay. This is one of the biggest factors why the logic if faulty. The assumption is that if project X and Y merge, developers from both projects will also merge. You can’t be sure. Because unless you are paying those developers, you can’t force them to stay with the project if they don’t want to, specially if they don’t like what’s happening. This assumption is probably based on most people presuming that there’s a central figure who dictates who should work on what project or part of the project, that there’s a boss that manages and allocates resources within the project. Alas, that rarely happens, unless that developer is employed, And even then, it’s not always that simple.
3. FOSS development is dynamic. It’s not static, disconnected, or completely independent, specially if the “duplicating” projects occur in a bigger ecosystem, like KDE. The two projects might grow up to be two completely different projects, they might start to develop a common library or backend or might already be using one. One might benefit from the advances made by the other. One might be complementing the other. One might disappear while the other remains. The point is that none of these is certain, everything changes. FOSS projects grow dynamically. It’s too early or too shortminded to say say with conviction that “merging X and Y” will work out completely.
Of course, this doesn’t mean that we shouldn’t also take risks. Sometimes merging 2 projects is the only logical solution. Sometimes there is no choice. In an ideal world, focusing available resources on a single project will produce the best results. Unfortunately, it’s not always so. It may work, or it may not. The point is that it’s not a panacea. It’s not a silver bullet that will solve all the development resource problems out there. So next time you begin to think of saying “they should just drop X (and Y) and focus on a single thing”, think again.
Just some small updates, while I'm trying to get off my ass and migrate the site completely to Textpattern.
December 5th, 2007 at 6:05 pm
I think there’s two parts to this. Whether it’s possible to merge two projects, or prevent one splitting apart — it isn’t. Developers do whatever they want of their own free will. And whether it would nonetheless be better if it were possible — in many cases, I’m inclined to say yes. Progress in many respects does scale linearly with manpower. If there had been a single desktop environment from the beginning, there’s a definite possibility that we could be laying siege to Apple by now, rather than competing with Windows. Or maybe not; and maybe without the pressure from GNOME, Qt would never have been GPLed. Nothing is certain. If it’s just idle dreaming, though (which it often isn’t), you can’t really deny people that.
December 5th, 2007 at 7:27 pm
@illisius: I don’t know how many software development projects you’ve been on, but progress most definitely does NOT scale linearly with manpower. Whole books have been written about this phenomenon.
December 5th, 2007 at 8:04 pm
Not always, obviously. In a project as large and diverse as a desktop environment, though (which is something like many smaller projects rolled together), I’d think it does.
December 5th, 2007 at 10:42 pm
Let’s not forget some other, more negative points:
*1a. Bad software design
The developer designs & implements the application so badly that other parties realize it will be cheaper to create a new application from scratch than try to enhance the current application with say a new UI frontend. It’s so much easier to use all the shiny Qt improvements through your application, and why bother building backend and frontend again, right?
*1b. Evil software design
Same thing, except now this is done on purpose. Too many times in the past there have been decisions like the following: “Let’s ignore the current solutions and invent FooBar Control Center, which would be so hard to port that we would be the only one who uses it even though we release it as free software! And users will consider it as an advantage!”
*2. People
Sometimes the forks happen not because of the code, but because of the mentality of the developers. Sometimes the fresh coder is too proud to admit his mistake and starts a new project where he is in charge. Or the other way around – the current maintainers are too stubborn to accept a feature the majority of the users asks for. I am sure you can think of an example. Alas, better software design can be taught, but better mentality can not.
December 5th, 2007 at 11:01 pm
It’s a good idea to read “Homesteading The Noosphere” before opining on this issue. Naysayers, take note.
http://www.firstmonday.org/issues/issue3_10/raymond/index.html
December 5th, 2007 at 11:22 pm
I think it’s also important to point out that projects are explorations into problem domains. It’s not like any project has a firm idea of exactly what they’re going to build and how and why. They evolve over time.
If everyone is working on the same project, then the problem domain isn’t explored as well. This is a problem that monopolies have (amongst others). It’s much better for the projects and users to have many projects with variances (members, experience, toolkits, build systems, use cases, requirements, …) and let the projects explore.
Because it’s open source, the projects watch one another and pick up the important ideas that work and skip the ideas that don’t.
December 6th, 2007 at 6:24 am
To clarify my ambiguous comment, I’m in agreement with the gist of this post.
December 6th, 2007 at 4:04 pm
@illisius: Progress doesn’t always scale linearly with manpower. There can, in fact, be instances when the more people working on something becomes the hindrance to progress (bike shedding, too many cooks, etc.). It’s not always quantity but also quality. But at the same time, we cannot discount the power of numbers. It’s a balancing act.
@mhb: Sorry, I don’t really see where you’re going with this.
1a. No one’s perfect. Newer, younger projects have the advantage of hindsight. They can see where their predecessor or colleague went wrong. Fixing the problem at the root might not always be possible (as your #2 shows) or feasible.
1b. Guilty until proven innocent.
2. True. There’s not much we can do about this, is there?
@Murrat: Thanks for the link. It will probably be a nice read.
@will: That’s my point. Projects are dynamic and evolve. It’s even more so in FOSS development because people are bound more loosely than in corporate scenarios. There is no “boss” to dictate what projects should be worked on and who should do it. In FOSS, the “boss” can make requests or recommendations, but in the end, it’s up to the individual developer. Unless of course your “boss” is really your boss.
December 6th, 2007 at 7:03 pm
Take Firefox vs. Epiphany for example; two projects with very similar goals. Let’s say I was a Python programmer that wanted to contribute an extension. I would be able to do this very easily with Epiphany, but I’d have to learn so much more to be able to do the same thing with Firefox.
Works the other way around, of course, too.
December 12th, 2007 at 11:53 pm
You seem to have ignored the argument that having multiple projects with similar goals permits innovation and progress spawned from the ether of a competitive spirit.