If I'd had a pound for every time some KDE user has said something
along the lines of "If I could code, I'd contribute to KDE," I
wouldn't be writing this on a laptop that was bottom-of-the-line when
I bought it three years ago.
So, if you're a KDE user who has at some time or another thought or
said exactly that, what can you do? Well, there are two options:
Learn to code! I get the impression that some people think that the
KDE coders entered the world with innate knowledge of C++ and Qt,
and wrote their first KDE application just before saying their
first word. They had to learn it just like the rest of us. It's not impossible to learn C++/Qt/KDE. Granted, it's not as easy as some other programming languages, but many
contributors have proved that it can be done: just ask annma.Get involved with one of the very valuable non-coding tasks that
help make KDE better. They range from writing docs and doing
translations, through artwork and usability studies, to maintaining
websites or doing bug triage. While these might not have the same
"wow" factor as coding that killer feature, or fixing that
long-standing bug, they're still extremely important to KDE, and
can be just as satisfying.
For example, take bug triage: KMail alone receives about 30
comments to bugs every day. The majority of these are users
either reporting new bugs/wishes or adding a comment to existing
ones. The small team of developers working on KMail can keep up
with these bugs a lot more easily if someone has already looked
through them and removed duplicates, confirmed those bugs which are
reproducible, and added any other useful information.
It won't make you the next Linus, but it's one way to get to know more
about KDE, and in the end it helps make KDE better.
I think I'll write a few blog entries over the next few weeks going
into more detail about specific ways to get involved. Maybe I'll even
polish them up enough to become dot articles. Which reminds me, I have
some notes of Aaron's "10 ways to get involved in open source" talk
which I should turn into full sentences so they can be article-ized.
posted by Philip Rodrigues @ 8:01 PM
6 comments
6 Comments:
I'd really look forward to blog entries on how to get involved, since thats exactly what I plan to do in a couple of months when I graduate from uni.
I already know how to program (doing a programming project in C++ as a substantial part of my degree), but it would be great to see some pointers of where to look for learning about QT and how to help out with KDE, I've already got a couple of ideas lined up for Konquest :).
One thing we have done at the KOffice project is to very actively seek out bugs that are simpler to fix than the rest and label them as JJ - Junior Jobs.
I don't know how many new coders we got that way, but I do know that it has been pretty successful.
Paul: I'm told that the Qt tutorials at doc.trolltech.com are pretty good - they even have a "How to learn Qt" section. I think in the timeframe you're looking at, you'd be better off looking at the Qt 4.1 docs than the 3.x ones, since you'd be looking to contribute to KDE 4. Docs for learning the KDE libs are a little bit harder. You might be able to find the "KDE 2.0 development" book by David Sweet et al, online, which, while obviously quite old, will introduce some of the important concepts. Good luck!
Divan Santana: quality.kde.org has lots of info on getting involved, and to some extent I'll probably just be repeating what's there. But it's fun to write, and think about things again, so I'll repeat away :-).
Ingwa: JJs are definitely a good idea. We ("KDE the project") should think about other ways to lower barriers to entry as well.
Since I was involved in the discussion that sparked this blog-entry (the discussion in KDE-quality, right?), I feel compelled to reply.
"Learn to code!". I'm sorry, but that's not really a valid suggestion to many. I for example simply don't have the time to learn coding. I work 45-50 hours a week (about 55 hours, including the commute-times), and my wife already thinks I spend way too much time on the computer. It's as simple as that. and I really, really fail to see why every time contributions are concerned, coding is the first one to be mentioned. Yes, you mention other possibilities as well, but coding seems to always be the #1. I don't really understand this pedestal coders have been hoisted upon. Just because someone can code does not mean that he's somehow more important than someone else. And just because someone can code does not mean that his input is by default more important IMO. Just because someone can code does not mean that he know anything about usability, artwork or needs of the users.
If KDE had 500 coders working on it full-time, does that mean that KDE would be destined to kick ass? No. If you don't have anyone designing the look and feel and usability (for example), things would start to suck very fast. Just because someone knows to code, does not mean that he's good at designing a desktop-environment. Desktop-environment like KDE is not about the code, it's about the overall system, in which code is only one part.
If we keep on hoisting the coders on a pedestal, while diminishing everyone else KDE will remain in a niche. Now, everyone will propably scramble on their keyboards to tell how highly valued documenters and the like are valued, then why are coders ALWAYS the first to be mentioned when we talk about contributions? Are coders "first among the equals"? Why does everyone think that coders are the ones that matter the most? "Because they are the ones who implement everything!". While that might be true, it doesn't automatically mean that they will do it right. I bet that many things in OS X were designed by total non-coders. If OS X was designed by coders, I bet it would look VERY different.
"write docs etc. etc.!"
many people propably do just that. But isn't this about doing what people want to do? That's what I hear all the time when people talk about coders. They code because they want to code. And it just might be that some non-coder is simply not interested in writing docs (for example), but they simply want to help out in ways that interest them.
I care about KDE, but I don't code. I haven't written any docs either (although I might do that if I find the time, I'm overworked as it is). So what have I done?
- Evangelized. I have demonstrated KDE to lots of people. I have showed them how it works, and I have hopefully increased KDE's user-base by a tiny fraction.
- User-support. I have spent lots of time helping other KDE-users with their problems, KDE-related or not
- Discussion. I have been quite active in KDE-related discussions. I have provided feedback, I have made suggestions, mockups and the like. And I have hopefully made a tiny positive contribution to KDE that way. Hell, Zack Rusin's description of KDE4's desktop-architecture (layers etc.) was almost 1:1 identical to a suggestion I had made on kde-artists.org few weeks earlier! Yes, it might have been a coincidence (great minds think alike ;). But what if it wasn't? does it still mean that I haven't "contributed"?
- Bug-reports. Yes, I have submitted bug-reports
I know very well how to contribute without actually coding. But if I do that, it takes about 5 minutes for someone to say "Well, I don't see YOU making this suggestion happen! So get coding!". After a while, it gets a bit frustrating. There seems to be some "official" non-coding related ways to contribute. But if someones contribution doesn't fit that "official" definition of contribution, it might as well not exist, and the user in question gets derided for "not helping out". I have been asked that "why aren't you contributing?". I am, but since it doesn't fit the "official" definition, it doesn't exist.
> Since I was involved in the discussion > that sparked this blog-entry (the
> discussion in KDE-quality, right?), I > feel compelled to reply.
Well, the discussion on kde-quality had something to do with it, but was by no means the only factor.
> "Learn to code!". I'm sorry, but
> that's not really a valid suggestion
> to many.
Agreed. I've never learnt to code, so I'm certainly not suggesting that everyone must do it. My point (which perhaps I failed to make very clearly) was that there's an attitude among some that being able to code is some god-given ability granted only to a blessed few gurus, and certainly not within the reach of mere mortals.
> and I really, really fail to see why
> every time contributions are
> concerned, coding is the first one to
> be mentioned.
For the simple reason that without code, applications are useless. You can write the clearest documentation, have the most usable mockups, and the prettiest artwork, but if your email client doesn't send email and your web browser doesn't browse the web, they're useless.
That's not to say that anything else is superfluous, but it has a different role.
<snip>
> "write docs etc. etc.!"
> many people propably do just that. But
> isn't this about doing what people
> want to do?
Basically yes, which is why I listed a wide range of possibilities, which wasn't meant to be exhaustive. There's the proviso that we'd like people to do things that are useful and needed (though no one can make them do those things), rather than just "what they want."
> I care about KDE, but I don't code.
Me too, and plenty of others.
<snip list of other useful things to do>
> - Discussion. I have been quite active > in KDE-related discussions.
This is an interesting point that I might come back to. (Basic thesis: discussion is useful, but only up to a point.)
> - Bug-reports. Yes, I have submitted
> bug-reports
I meant bug triage, which is quite different, but anyway, the blog entry wasn't about you personally, and so while it's good that you've done the various things, it's quite orthogonal to the point I was trying to make.
> There seems to be some "official"
> non-coding related ways to contribute.
> But if someones contribution doesn't
> fit that "official" definition of
> contribution, it might as well not
> exist.
I'm sorry you feel that way. There are some reasons for this, one of which is that there are existing forums for particular subprojects, and it's most useful to direct your efforts through the appropriate place. To make up a silly example, if someone posted a patch that fixed some code to the docs list, we'd tell them where they should send it instead (viz, kde-(core-)devel). They haven't been ignored, but they'll get much better results by fitting into the existing region of the project that already deals with such things.
Anyway, as I've already said, this entry wasn't mean to refer to or attack you personally, so I'm sorry if you took it that way.
"For the simple reason that without code, applications are useless"
But just because there is a bunch of code floating around, does not mean that the application is useful. Sure, you might create a "Hello World!", but on a complex system like KDE, the importance of the coders diminished, whereas importance of other people (documenters, artists etc.) is heightened. Well, IMO at least.
"Anyway, as I've already said, this entry wasn't mean to refer to or attack you personally, so I'm sorry if you took it that way."
no need to worry :). I didn't feel that it was directed towards me as such, nor did I feel that it was an "attack" of some sort :).
Post a Comment
<< Home