Skip to content

Contributing to SyncEvolution

I recently wrote an email about my own private “laundry list” of items that I look at when deciding whether I contribute to a project. Now I would like to check how SyncEvolution fares in that litmus test. If it doesn’t pass, perhaps I should stop working on it ;-) Seriously, I’d really like to encourage other developers and users to contribute to SyncEvolution. Let’s see what I might have to do differently so that you can and want to do something… I Want You… To Sync!

Motivation for Contributing to an Open Source Project

  • Scratching an itch: the project has to solve a real problem that I have. Otherwise I typically do not bother – life is too short… There must be something obvious that I can contribute.
  • Clean code base that is fun to work with: I don’t mind learning a new language or technology, quite the opposite. Learning from people more experienced is part of the joy of open source. Working with code which is obscure, poorly documented, uses bad style or obsolete techniques is deterrent.
  • Good software development techniques: using regression testing on all relevant platforms is important. Besides encouraging trust in the project in general, it has the advantage of helping me to check that my changes do not break anything before suggesting them for inclusion and (in case that I cannot run the checks on all platforms) helping the project owners themselves to detect if I broke anything.
  • Communication with the main developers: response times to inquiries do not have to be quick, although that is a benefit. It’s more important that they are deterministic. What I mean is that a guaranteed response, say, once a day, is better than multiple emails per day followed by a week of unexpected silence. In the later case I’m left hanging high and dry and might be stuck with the work which depends on that response; I cannot plan my work either. It’s also important to understand who has which role and how decisions are made (see also next point).
  • Clear and easy path for patches into the release: what are the requirements (technical and legal)? How often are patches integrated? Is it obvious who has the final say about that? Is there constructive feedback on what needs to be changed to make a patch acceptable?

Contributing to SyncEvolution

I started SyncEvolution because I needed a working sync solution for Evolution. If you prefer some other program that has no working SyncML client, then I’d be happy to help with integrating support for it into SyncEvolution. I’m currently rewriting the configuration handling and as part of that also simplify adding new sync sources (= the classes which access local data). I’ll write more about that soonish.

There is full automated regression testing for all aspects of SyncEvolution. Therefore changing it is relatively safe. New sync sources can also be included in the testing easily.

Once the code for a new sync source is ready, binaries could either be released separately or we can collaborate on getting it into the hands of users as part of the normal SyncEvolution. For SyncEvolution I would like to keep copyright consistent within source files (think of the problems the Linux kernel has if they ever want to switch to GPLv3), but sync sources are self-contained and no copyright transfer would be needed for that.

I’ll refrain from commenting on the quality of the SyncEvolution source code or my own skills: of course there’s no doubt that I am such a 1337 coder that this goes without saying ;-) Ahem, right. Better check out the source code yourself. I tried to add as much comments as necessary to make getting started easy. No additional documentation should be required – at least that’s the goal.

Communication could be a problem. I have a day job and a real life, so I can only reply to emails during the evening (German time) or the weekend. There are phases where I do that less frequently. Overall I think I manage to keep up with inquiries reasonably well and reply at least every few days, often every day.

Even if you are not a programmer, there are other items that I could need help with: for example, I wanted to convert the README into Perl pod format for ages so that I can build man pages and text files for the release. The estamos.de pages would also come from the same input.

Post a Comment

Your email is never published nor shared. Required fields are marked *