[clug] development topic for clug talk?

Brad Hards bradh at frogmouth.net
Tue Aug 23 05:15:04 GMT 2005


On Mon, 22 Aug 2005 23:20 pm, Pascal Klein wrote:
> Just out of interest, would someone be able to give everyone (or me, if no
> one else is interested) some advice concerning how development happens in
> the GNU/Linux community.
I think that this is, in some ways, a very hard question to answer. Like most 
reasonable size communities, the GNU/Linux community comprises of a number of 
smaller groups. Those groups have varying levels of maturity, varying levels 
of cooperation inside the group, varying levels of cooperation with other 
groups (and the broader community), and widely varying expectations of their 
members.

As an active user of GNU/Linux, you are part of the development process. How 
much a part you are, and the influence that you exert depends on that 
activity. For example, if you file a bug on a bugzilla somewhere, then you 
are contributing. If it is a really high quality bug report (say, full steps 
to reproduce the problem, a backtrace from a non-stripped build, and a patch 
that fixes the problem) then you obviously have more influence than a bug 
report that says "your app crashed! you all sux0r".

The other thing that is really important to understand is that there is no 
management layer for most communities. It isn't a company - it is a bunch of 
people working together. This is why you can't show up on a mailing list and 
say "I'd like to help - where should I start?" - there is no-one in charge to 
direct you.  You need to find your place in the community - how you do that 
depends on your skills, interests, and the time you can put in, and 
(obviously) also the particular community that you are trying to become part 
of.

General things that help:
* understand the environment in which the community exists. For example, the 
kernel developers mostly work by mailing lists, while other communities do 
more stuff by IRC or Instant Messaging type tools. Web forums and Usenet are 
less popular, but still possible.
* first listen (read), then speak (write). You need to work with the 
community, not across it. You need to understand the current situation within 
that group. For example, if the project is in feature freeze, then providing 
a new feature will likely get your work ignored - you'll only end up 
frustrated.
* actions count. If you want to be taken seriously, you can just propose ideas 
and never deliver. 
* remember that it isn't that important - it is just a hobby, so when you stop 
enjoying it, find something else to do (either a different project/group, or 
something that doesn't involve software at all)

A specific example. Since you mentioned graphics and documentation, then  
might be interested in KDE (perhaps you already use it?). KDE's artwork is 
mostly coordinated on a mailing list (see 
http://www.kde.org/mailinglists/#development), with some work on IRC 
(#kde-artists) and a couple of websites (http://www.kde-look.org and 
http://www.kde-artists.org).  Similarly, documentation uses a mailing list 
(kde-doc-english) and a little bit of IRC (#kde-docs).
If you need an idea of what to work on, then it usually works best if you work 
on something that annoys you (eg there is no documentation for your favourite 
application, so you write it). If nothing comes to mind, you can often get 
some ideas from the bug tracker (eg http://bugs.kde.org). Some project keep 
simpler tasks for new-comers - in KDE they're called "Junior Jobs" or JJ, and 
the bug tracker has a special search just for those.

If all else fails, approaching people at CLUG (especially over pizza) might 
help (although I won't be at the next one - I'll be en-route to 
http://conference2005.kde.org :-).

HTH

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20050823/34ccf929/attachment.bin


More information about the linux mailing list