Every once in a while some guy publishes his rants as an article. This time it was Nathan Willis with his “When open source projects close the process, something’s wrong”. Since this is a great example of how articles should not be written, I’ll use it to tell about good journalism.
I hope you’ll excuse the fact that I’ve been working as IT journalist for seven years only (and as editor in an offline IT magazin with >100K copies run per issue several years ago). Not that much, but still a nice experience.
There are several simple rules in journalism.
1. Make sure the issue really exists.
If you are a good journalist, you don’t play with people’s minds and you don’t make up problems. You investigate, analyze and tell.
Nathan: “Twice in recent weeks open source projects have surprised me with their lack of openness. In both cases, developers acted or spoke out in such a way as to intentionally push other developers away from their work.”
Neither of parties tried to “intentionally push other developers away from their work”. In the first case we have a designer and a spokesperson who express disagreement with people not having respect for their (or, rather, Oxygen designers) work. In the second case amount of decision makers is intentionally limited to maximize signal/noise ratio, while amount of contributors is not limited at all.
Is it really worth a rant, not even speaking about an article?
2. Research, don’t guess
Nathan: “Through the Internet Archive’s Wayback Machine, you can examine the Oxygen project’s site all the way back to 2005. Ever since the beginning, two things have remained unchanged: the only images available are “previews” licensed under Creative Commons Attribution-NonCommercial-NoDerivs, and the team does not invite outside participation.”
OK, I look at the archive and I see that the website hasn’t changed. How does it related to openness of the project?
Instead let’s go straight to Contact page of Oxygen project:
“To get involved you can join the KDE Artists mailing list where everyone is encouraged to contribute, share ideas and offer help. You can also discuss Oxygen on IRC (freenode.net #kde-artists).”
Does it sound like the team is not inviting outside participation? Clearly it doesn’t. Every conclusion you make should be backed by facts. If you intend to prove that Oxygen team doesn’t welcome contributors, use facts: tell readers about people who actually studied principles of Oxygen’s approach to design, tried to contribute, but were rejected from participation. If such people ever existed.
Nathan: “But that absence of an open invitation to contribute is topped by direct rejection.”
Is it the same Nathan Willis who earlier wrote “When I researched the GIMP UI brainstorm in October…”? Research is the wrong verb here. Looking through is the right one. You wanna proofs? Here you are.
a) We can see Sven saying: “The process is completely open and you have obviously misunderstood quite a few things about it. … Can we please not distract ourselves right now with a discussion that is based on nothing but fear, doubt and misunderstandings? Thanks.”
b) “Participate in the UI brainstorm” is listed among “Ways in which you can help” at GIMP’s website.
The term direct rejection is a clear case of no good research at all. For every conclusion you needs solid facts. To get solid facts you have to research.
3. When writing about a conflict situation, talk to both parties.
This is not even an option like buying or not buying ice-cream in a supermarket. This is golden rule. If you don’t follow it, go blogging elsewhere.
- Did Nathan contact the creator of “Oxygen Refit” icon package to ask him if he was really abused? Since this is not mentioned, I’d say, no — the guy wasn’t contacted. You say you disagree? Then prove me wrong. Use facts.
- Was Oxygen team contacted to provide comments? Not mentioned in the article, therefore not contacted.
- Was Esteban contacted to have him say he was abused by GIMP UI design team rules? Looks like he wasn’t as well. Too bad, because after initial misunderstanding, how the UI design project works, he keeps contributing. To the “closed” project
- Was GIMP UI design team contacted to provide explanations? All the same.
Googling and quoting isn’t enough. Go blogging, if you think it is.
4. Tell, but don’t teach.
Nathan: “The secondary complaint — that it is wrong to release the icons before the project declares them “ready” — is entirely incompatible with the “release early, release often” philosophy. Artwork is no different from executable code in either regard.”
A journalist is not supposed to teach (unless he writes tutorials), especially in an agressive manner. Never. Ever. Primary function of a journalist is to tell people what is going on. If you try to be both journalist and evangelist, you will fail at both. This is simple.
Anyone mad about the way Oxygen project works? Buy a punching ball and contribute to it.
Just for the record, I’m not affiliated with Oxygen project. I’m a tiniest bit affiliated with Tango project and I did feel angry about this silly Tango vs. Oxygen opposition. They are good friends.
5. Learn what you are writing about.
A good journalist can write about just anything at all. Sure, noone would expect a great SAN related article from someone who has been writing about agriculture for last 30 years. But if you are an IT journalist, you have no excuse for not knowing basics.
Very few users use most of functions in an aplication like GIMP. Therefore they can contribute with ideas how to improve a small part of the application, but they can’t be great UI architects, because they don’t see the big picture. As simple as it is. Basics, as I said before.
Now think about reasons, why decision making is limited to Sikking’s team. And think about the way OpenUsability project works (and it wasn’t even mentioned in the article — another sign of no proper research).
That’s it. Five rules is enough for now.
Oh yeah, and because this blog posting is about teaching, you are free to consider it a rant
