Scientific papers always have a “related works” section, where the authors describe how the work they are presenting compares with what others did. In the Free Software world, this is nearly non-existent: in a way, it seems that many of us are thinking of their projects as competing products, fighting for market share. On a project web page, I would love to read something like:
This project is particularly well suited if you want XX. But if YY is more important to you, you might want to have a look at ZZ.
Or simply links to similar projects for other environments, etc. All in all, I think that the goal is to improve the global satisfaction. Not to win a few users, who won’t be totally happy, because the project doesn’t really suit their needs.
While some projects cooperate and share ideas, like I think desktop environments do inside freedesktop.org, most just ignore each other. I am both a Debian and an Ubuntu developer, and I’m sometimes amazed that Ubuntu discusses technical choices that were discussed (and solved) a few weeks earlier in Debian. And it’s even worse with the other big distros out there.
Couldn’t we try to improve this ? We could just create a mailing list, where developers from various distributions could present the way they do things. This would allow to discuss future developments (“We are planning to improve this, what are you doing about that ?“) or simply to improve people’s knowledge of the various distributions.
Of course, this could easily turn into flamefests, but they are technical ways to avoid that, like moderating posts from trollers…
Does something like that already exist ? Do you think that it would be interesting ? Would you like to contribute to such a forum ?
Some examples of things that could be discussed:
- How many packages do you have, and how do you support them ? Do you have several “classes” of packages ?
- How do you manage your releases ? Goal-based ? Time-based ? Bug-count-based ?
- Which kind of quality assurance do you do ?
- How many contributors do you have ? Are they split into different “classes” ? Who has “commit rights” ? Can you give out “commit rights” restricted to subsets of your packages ? A organized sponsorship system for people who don’t have commit rights ?
- etc, etc, etc.