I can try and do more coding, more code reviewing, revive designing discussions… that’s cool, yet never enough. GIMP needs more people, developers, designers, community people, writers for the website or the documentation, tutorial makers… everyone is welcome in my grand scheme!
Many of my actions lately have been towards gathering more people, so when I heard about the GNOME newcomers initiative during GUADEC, I thought that could be a good fit. Thus a few days ago, I had GIMP added in the list of newcomer-friendly GNOME projects, with me as the newcomers mentor. I’ll catch this occasion to remind you all the ways you can contribute to GIMP, and not necessarily as a developer.
Coding for GIMP
GIMP is not your random small project. It is a huge project, with too much code for any sane person to know it all. It is used by dozen of thousands of people, Linux users of course, but also on Windows, OSX, BSDs… A flagship for Free Software, some would say. So clearly coding for GIMP can be scary and exciting in the same time. It won’t be the same as contributing to most smaller programs. But we are lucky: GIMP has a very sane and good quality code. Now let’s be clear: we have a lot of crappy pieces of code here and there, some untouched for years, some we hate to touch but have to sometimes. That will happen with any project this size. But overall, I really enjoy the quality of the code and it makes coding in GIMP somewhat a lot more enjoyable than in some less-cared projects I had to hack on in my life. This is also thanks to the maintainer, Mitch, who will bore you with syntax, spaces, tabs, but also by his deep knowledge of GIMP architecture. And I love this.
On the other hand, it also means that getting your patch into GIMP can be a littler more complicated than in some other projects. I saw a lot of projects which would accept patches in any state as long as it does more or less what it says it does. But nope, not in GIMP. It has to work, of course, but it also has to follow strict code quality, syntax-wise, but also architecture-wise. Also if your code touches the public API or the GUI, be ready for some lengthy discussions. But this is all worth it. Whether you are looking for improving an already awesome software, adding lines to your resume, improving your knowledge or experience on programming, learning, you will get something meaningful out of it. GIMP is not your random project and you will have reasons to be proud to be part of it.
How to choose a first bug?
Interested already? Have a look at bugs that we think are a good fit for newcomers! Now don’t feel obligated to start there. If you use GIMP and are annoyed by specific bugs or issues, this may well be a much better entrance. Personally I never contributed to fix a random bug as first patch. Every single first patch I did for Free Software was for an issue I experienced. And that’s even more rewarding!
Oh and if you happen to be a Windows or OSX developer, you will have an even bigger collection of bugs to look into. We are even more needing developer on non-Linux platforms, and that means we have a lot more bugs there, but also most likely a good half of these are probably easy to handle even for new developers.
Finally crashes and bugs which output warnings are often pretty easy since you can usually directly investigate them in a debugger (gdb for instance), which is also a good tool to learn if you never used. Bugs related to a graphical element, especially with text, are a good fit for new developers too since you can easily grep texts to search through the code.
Now there are whole other areas where you could contribute. These are unloved area and less visible, which is sad. And I wish to change this. One of these is infrastructure! GIMP, as many big projects, have a website, build and continuous integration servers, wikis, mailing lists… These are time-consuming and have few contributors.
So we definitely welcome administrators. Our continuous integration regularly encounters issue. Well as we speak, the build fails, not because of GIMP, instead because minimum requirements for our dev environment are not met. At times, we have had a failing continuous integration for months. The problem is easy: we need more contributors to share the workload. Currently Sam Gleske is our only server administrator but as a volunteer, he has only limited time. We want to step up to next level with new people to co-administrate the servers!
While we got a new website recently (thanks to Patrick David especially!), more frequent news (here I feel we have to cite Alexandre Prokoudine too), we’d still welcome new hands. That could be yours!
We need documentation for GIMP 2.10 coming release, but also real good quality tutorials under Free/Libre licenses. The state of our tutorials on gimp.org were pretty sad before the new website, to say the least. Well now that’s pretty empty.
Of course translations are also a constant need too. GIMP is not doing too bad here, but if that’s what you like, we could do even better! For this, you will want to contact directly the GNOME translation team for your target language.
And finally my pet project, I repeat this often, but I think a lot of GIMP workflow would benefit from some designer view. If you are a UX designer and interested, be welcome to the team too!
So here it is. All the things which you could do with us. Don’t be scared. Don’t be a stranger. Instead of being this awesome project you use, it could be your awesome project. Make GIMP! 🙂