GNOME Love is a wonderful and important initiative for GNOME Project. Having experienced developers helping people who want to get started contributing to GNOME is really great. GNOME Love Day should be happening more often…
IMHO, we could improve our relationship with the potential new contributors by “asking them” what are the main barriers they find on trying to contribute (documenting, translating, coding, testing, etc, etc, etc.). There could be a survey on this to raise more information about it.
I’ve been talking with some people who’d like contribute but just did’t get it and the reasons they give range from “I don’t know where to begin” to “The platform is too ‘complicated’ and it’s not well documented.” or “I’m not capable to contribute in such a big project.” and so on. This barriers can be psychological (self-esteem? unclear initial steps? project is too big?), social (community is not receptive? contributions not being considered?), technical (bad platform docs? gobject is too complicated? don’t know C programming?), cultural (don’t speak english? doesn’t have local group to share knowledge/information?), and so on (don’t consider these examples as real. they’re just random ideas).
By raising such information we could build better strategies for GNOME Love and other sub-projects. For example, if the cultural reasons are prominent, we could invest more on the creation of local groups. If platform is being perceived as ‘complicated’, we could invest on high level docs like tutorials about certain technologies. If there are too much contributions from new contributors that are not being considered, we really should check why this is happening.
I’m sure there lots of potential contributors reading this post that have lots of things to say about it!
Comments?
Like being ignored? [1] [2] [3]. After these experiences I will be more reluctant to put any effort in to contributing in the future. I’m seriously thinking of just helping the KDE project instead.
You think you’re being ignored? Look at this list!
I manage an embedded software team and do most of my programming in C/C++ for WinCE as well as our own in-house kernel designs. Outside of work I tend to enjoy Qt and by extension KDE for its structured and documented environment. Gnome seems rather chaotic. It always seems to be going in too many directions at once. Perhaps a good deal of that is the result of the particular interests of the companies that that back Gnome.
My personal experience is that when I tried to contribute something, I was ridiculed by several people for doing it the “wrong way” by the cool kids. It really soured my own willingness to devote my free time to the project, though I am still an avid fan of the platform.
A couple of years ago I had decided that I would like to contribute to the GNOME project. I have quite a bit of experience with C, but very little with the GNOME platform. My plan of attack was to get a CVS HEAD build of GNOME running, find an easily reproducible bug (and hopefully fairly easy to fix) in bugzilla, and start working.
I basically never made it past step one. I was using jhbuild (which I loved) to build GNOME from CVS, but I found to my dismay that GNOME in its entirety is almost never buildable (or wasn’t at the time). I didn’t just try a few times. I tried at least a couple of times a week over the course of a couple of months. Not once was I able to just start up jhbuild, leave for a while, and come back with a successful build. I was generally able to fix things and continue the build if I spent enough time on it, and I got CVS builds of GNOME running on several occasions, but it would literally take me all day just to do that (usually it was autoconf erroring out for one reason or another rather than a compilation failure). Ultimately I decided that I was spending all of my time on just trying to build GNOME and no time actually working on it, so I gave up and moved on to more rewarding projects.
I’ve seen mention of somebody (Luis Villa?) setting up a tinderbox machine since then, but I have no idea what the state of that is. And maybe things have changed since a couple of years ago. But I was surprised that CVS HEAD was broken as often as it was.
I totaly agree with Thomas… Having a working jhbuild is just a hasle, even with the help available here: http://live.gnome.org/CategoryJhbuild
Just compiling a *released* version is pretty difficult without a few hacks… never managed to have a running platform with a single “jhbuild build”. So imagine when compaling an unstable version and that someone breaks the cvs… you just don’t know why, and just have to wait a few days, or know a date when it worked and have some cvs knowledge.
The other important problem of the GNOME platform is the documentation. Outdated information available at developer.gnome.og harms more that does good. Theres no centralized repository for tutorials, and many tutorials available are in html, so it’s not easy to update them when they become outdated, unlike their wikified counterparts.
For the simple question “how should I create a menu in a gtk app”, information on developer.gnome.org would talk me of bonobo, while live.gnome.org would send me to GtkUIManager… Kinda hard to know what is the right way to do something.
We really need a centralized (and wikified, I think) version of all the “moving” documentation (code, cvs, jhbuild, etc… tutorials) and AVOID INFORMATION DUPLICATION !!!
I’m a visual sort of person, and I was baffled by the non-existance of any sort of map to GNOME. I’ve finally found some sort of foothold through mono and its libraries and tutorials, but even that is pretty rough.
The sheer volume of C code required to do anything trivial really pushed me away. I can read and write C well enough, but I prefer to avoid it, as I’ve discovered C’s somewhere between ASM and Java. When I’m trying to learn an architecture, a concept, pages of C code get in the way of a six word idea.
I still find it easier to write wxPython than GNOME code. The wxPython demo and documentation go hand-in-hand, and it’s terribly simple to do almost anything. I didn’t find anything comparable for Gnome. The best stuff is in the mono Gtk stuff.
I also want to second the difficulty of building GNOME. It’s an exceptional event when autoconf successfully AUTO confs.
I made two simple searches on google, “building Gnome” and “building KDE”. Here are the first results:
http://www.gnome.org/~newren/tutorials/developing-with-gnome/html/ch04.html
and
http://quality.kde.org/develop/cvsguide/buildstep.php
The difference of quality is obvious.The Kde doc is on the Quality part of the KDE site which is a good place. The Gnome doc is on an unknown account, “newren”, on the Gnome site. Moreover, I don’t speak about the quality and the organization f both contents.
We have to take some examples from other projects.
I’ve started a mockup of what should be done IMHO:
http://live.gnome.org/Developer_2eGnome_2eOrg_20Must_20Die
Feel free to add your comments to the wiki
For me the greatest barriers are
– gobject/gtype system; It’s simply not enough to understand object oriented programming on a Java/Python-like level (unless you target projects using these languages). Documentation/tutorials on the basic level of this is very sparse (but seems to be getting better).
– building the platform; I’ve never succeded in building Gnome. Not with jhbuild or garnome – you name it. – And I’m a guy regularly building my own kernels/.debs/whatever…
– autotool understanding; I’ve had a very hard time understanding basics of autotools (I mean totally basics!)
Cheers
I don’t know about anyone else but I get really pissed off and discouraged by the way most bug reports and requests get closed with very little explanation.
Developers could do a lot more to encourage people on how to do things the right way, and learn to provide something more to their liking rather than berating people for not magically knowing how they like to do things. It is not like most developers have clear documentation on how they like things done and what bugs are beyond the scope of their work or available resources). Knowing what to expect means users are less likely to have unrealistic expectations and be disappointed. (I suppose there is probably more I could do to explain to beginners how best to use the mailing lists but I would largely be repeating what Eric Raymond wrote about asking good questions to get good answers.)
Interesting comments have been made about how maintainers barely have the time to review and check other peoples work but I think that highlights the important distinction between a developer and a maintainer. I believe maintaince is less about development and programming and more about management and delegating tasks. Even if it would be easier for the skilled developer to do the easy things themselves sometimes it is more important to try to help get the beginners to work through the problem themselves. Most of the time extra effort may not have any benefit to the developer – you must accept that and have realistic expetations or face regular disappointment – but occasionally taking the extra time to manage users, to encourage interest and divert it somewhere useful a developer can create repeat contributors instead of expecting it to happen magically as we have done in the past. Some people are born with huge enthuasiasm for this kind of thing, others need more encouragement.
(I believe those who are lucky enough to be working on Gnome proffesionally have a particulary obligation to be civilised and not poison the enthusiasm of volunteer contributors but of course I’m on the other side of the fence and I would say that.)
> Posted by anon at Mon Dec 19 2005 01:53
> My personal experience is that when I tried to contribute
> something, I was ridiculed by several people for doing it
> the “wrong way” by the cool kids. It really soured my own
> willingness to devote my free time to the project, though
> I am still an avid fan of the platform.
Chances are the in crowd didn’t even realise what jerks they were being. It goes to show the importance of the silent majority to speak out and tell others to try to be more polite, and to consider the unwritten rules* of our community are not obvious to outsiders. I’d like to think there were some community leaders you could go to and privately explain you how you felt you weren’t given a fair chance. When I was getting started I was lucky to find some particlarly friendly projects (in general I find the developers of cross platform software are less elitist a lot more considerate and have seen it all already) but if you are not lucky try another project which interests you and you may need to try a few until you find a place you feel your efforts are appreciated.
* With perfect 20/20 hindsight trying to write down and codify the unwritten rules is another obvious idea.
I never got Jhbuild working. I started by getting the most recent copy of $DISTRIBUTION and trying to find problems and then checking to see which ones were still not fixed in CVS.
Gradually the lag between CVS and distributions got so frustrating and so many of the problems I found were already “fixed in CVS” I would try to compile the specific application I was interested in from the most recent tarball available. This would work occasionally but more often than not my toolchain was too far out of date and to many bits needed to be updated. Thanks to the university I had the luxury of a fast connection and a few Gigabytes of scratch disk space which I could use temporarily (but which got wiped regularly) so after a few false starts and a fair bit of learning Garnome provided a relatively easy way for me to bootstrap a fully up to date toolchain and compile individual applications I wanted to test, or compile the entire desktop. Garnome put me on the cutting edge, although not on the unstable bleeding edge of CVS (which might not even be buildable) and I felt this was more than enough. No reasonable developer could really blame me for being only one or maybe two releases behind because if CVS had drifted so far from the last release there was plenty of responsiblity to go around. Maybe others will try Garnome, I found it a lot less of a struggle than jhbuild.
[Hmm, this comment turned out a lot longer than intended]
I agree with most things said above, especially about the difficulty of building with jhbuild and the lack of up-to-date documentation. I tried a couple months / years ago to get a cvs build of gnome up and running to try to help out with bug triaging, etc. It took forever to work through all of the build issues and when I finally did get a build running, I was never confident that the issues I ran into were actually bugs and not due to some workaround I’d done to try to get things to build or from some lower-level library that wasn’t up-to-date or something of that sort.
I’ve only recently started trying to contribute again, this time to gtkmm. I’m using jhbuild to build the latest version of gtkmm and its dependencies. In between my first attempt at building gnome and my recent foray into helping out with gtkmm, I started my own open-source project and in the process, learned a lot about the gnome libraries, autotools, and things of that sort. So this time, I’ve had a much easier time getting things to build (as can be expected), although I’d guess part of the reason it’s easier is also that I’m not trying to build the whole desktop — I’m stopping slightly lower in the stack by just building gtkmm and dependencies.
Anyway, my point is that when I first started trying to contribute to gnome by triaging, I was always told that helping out with bug days didn’t require a lot of programming knowledge — it just required you to show up and help confirm bugs, etc. Well, this is technically true I suppose, but it presupposes that you’ve got a GNOME desktop built from CVS, which in fact *does* require quite a lot of programming / technical knowledge to accomplish. And although I’ve gained a lot of experience and knowledge from my personal project over the last year or so and am now somewhat comfortable with autotools, make no mistake, the autotools are a complex and byzantine thing that I still get lost in from time to time. Autotools provide some wonderful functionality and overall make life much easier, but there’s a very steep learning curve and as such I think it’s probably the biggest obstacle stopping people from contributing to projects like GNOME. It’s heartening to see this issue being brought up and discussed seriously on desktop-devel right now.
I must say that the C language and things like GObject are also a bit of an obstacle and personally scare me away from contributing much to programs in the core GNOME desktop. But fortunately gtkmm is a fantastic C++ library and allows me to contribute in a language that I feel comfortable with.
I’ve been really fortunate so far with my gtkmm work to have a very good maintainer to work with, which helps a lot. Murray’s been very helpful and prompt with responding to my questions and bug reports. And I’m mostly concentrating on improving the documentation for gtkmm right now, which I believe is one of the other big obstacles for people attempting to get involved with GNOME.
For me it is solely the pain that is C programming which drives me away from contributing to GNOME. I keep wanting to try and pulling in the source via CVS, but every time I open it up it just looks so verbose and low-level that it gives me a headache.
Maybe I’m just a wuss, but I feel I have better things to spend my time thinking about than memory management. It is encouraging to see increasing use of Python, and the Ruby-GNOME2 project makes me very very happy.
I tend to agree that the C language is the biggest turnoff. I am much more at home in C++. I get the impression when it comes to Gnome that gtkmm is an interesting project but still a work in progress.
I can’t comment for the atitude of the developers. As an electrical engineer myself I find the notion of “hacking” quite an odd term. I am used to working with version control systems like Borland’s StarTeam and doing software development with software design plans and schedules. We don’t have to deal with a flurry of patches from various sources of dubious quality and testing. So I have a great deal of sympathy for the devs and maintainers of the various code. If my software engineers had to deal with patch submissions from around the world and try to make sense of them and roll them all into a release, it would be tough to bear over time.
So I appreciate the contributions of the devs and maintainers and recognize that the nature of the software patch system used in FOSS kind of lends itself to the state things are in.
I guess you need to strike a balance between the way things are now and taking time out to really document and provide some sort of training for folks working on Gnome. Otherwise, it is not going to get any better.
Sean Kelley
My biggest stumbling blocks to contributing, from my experiences, are:
1. The size of the steps – to go from a simple idea to a “standard” buildable project, you need to learn
a. Autotools
b. Which libraries to build with
c. GObject/glib (and this one is huge)
This is substantial, even if you’re experienced with C (as I am). Throwing in GObject is pretty much like learning a new language, which is hard to do by just reading API docs (some of which don’t have anything but the function prototypes).
2. Knowing where to start – I’m very familiar with GNOME from the user standpoint (I know what a lot of the sub-projects do, etc.), but I still have difficulty knowing where to go to get started. The tutorials page on the GNOME development site (http://developer.gnome.org/doc/tutorials/) includes a bunch of tutorials, but doesn’t have a general one which builds a simple program, piece by piece. A multi-part tutorial (one for autotools and libraries, one for a simple command-line program, one for a simple GUI) would be especially helpful.
3. Time commitment – it seems hard to build up experience/knowledge of GNOME development in increments of an hour or two, which is about all I have at a time, as a university student. Maybe it’s unreasonable to expect this, but each time I get started, I fumble a little without getting very far, then end up having to move on to something school-related. I had similar experiences while working a 40-hour workweek (though in that case, I had been programming all day already. It’s harder to work on code when you’re tired of it).
jonner: You do not need jhbuild to help with triaging. A lot of the reported bugs are duplicates. Searching for duplicates doesn’t require a jhbuild installation. Crashers can be easily checked for duplicates by using the simple-dup-finder.
Reading *a lot* of bugreports helps, but it is not required.
I normally use the packages from my distribution (Mandrive Cooker) coupled with http://gpwgnome.osknowledge.org/ (contains the development packages for GNOME). Every once in a while I update my jhbuild installation for a better stacktrace, but now that gpwgnome includes debug packages I probably do not have to bother. Even then, I do not often use it for confirming, more for myself (I like having the latest stuff as soon as possible).
I do agree with some of the comments appeared before:
First of all, getting a functional build of Gnome can be a really difficult task. I think that the main problem is the fact that the instructions/dependencies are different for each distro.
There has been an effort to document the necessary dependencies at http://live.gnome.org/JhbuildDependencies, but it’s difficult to maintain it for all the existing distros and all their versions.
Maybe the following is an stupid idea, but could it be possible to build periodically an image of some distro with a pre-built Gnome (and all its source) to run it with some virtualization program like VM Player, Xen, etc.? This would make easy for testers or for beginners to start working on latest versions of Gnome…
Another problem commented by Travis Reiter is the fact that there are a lot of packages involved in Gnome, so trying to understand what does provide each of the packages and how to use them to write a complete program can be a really overwhelming task.
I do agree with him that documenting the creation a program piece by piece could be a good point. Maybe another good point would be to write small programs involving the documented packages which demonstrate the functionalities provided by the packages.
Social barriers are an important problem.
Too many mailing lists and IRC channels are home to only tumbleweed: you ask a question or send in a patch and get no reply at all. It can get very discouraging and frustrating.