Skip to content

Contributing to Open Source – The Good and The Bad

I am not a big contributor to Open Source. If you don’t count the random code that I have written in my blog and host on GitHub, I have only made two real contributions. But the difference between these two is so big, and the way they ended is so different, that I had to write about this.

My first contribution was to the scribe-java project, which is a Simple OAuth library for Java hosted at GitHub. I was trying to access the Mendeley API from Java and searching for an OAuth library, found scribe. But it was missing a Mendeley handler. So I cloned the repository on th 11/09/2013, added my small changes (one file, ~50 LOC), created a pull request, got reviewed and some changes were required, did the changes and on the 13/09/2013 my changes were already part of the main branch. Fast, no hassles. Makes you want to contribute more.

The second contribution started as an Eclipse Bug/Enhancement – Why not add a search box to the Eclipse properties view? Very fast I was answered that the best way for this to happen was to do this myself. So I cloned the Eclipse UI repository on the 15/02/2013 and after some coding, pushed my changes on the 17/02/2013. Two days after I got a comment in the bug asking me to make some changes in the implementation. I was also told that if the change is more than 250 lines we need to do a CQ (whatever that is) and the deadline has passed so this may have to way. No problem! So after asking some more clarifications on how the code was expected to look, I went back, did some more fixes, and pushed again on the 21/02/2013. This time I got more comments, which started making things harder. First, the Eclipse UI must compile against Java JDK 1.4! WHAT? 1.4 is EOL!!! Why is eclipse still supporting it? But hell, who cares? I’m contributing here :-). Oh, but in 1.4 the String class does not have a contains(String) method. What am I to do? Easy! the Java code is open everywhere, so I can copy the code that is currently used in Java! Code, code, build, and push, on the 11/03/2013.

Oh… seems that the Java code is GPL… so it can’t be used in Eclipse (which is EPL). Need to make some small changes, from:

indexOf(s.toString()) > -1

To

indexOf(s.toString()) >= 0

You see the difference? This is a COMPLETELY different way to search for a String inside another String. I hate lawyers! But I’m doing something good! I’m contribution to Open Source! Code, code, and Push on 12/03/2013.

After waiting for one month, I updated the bug asking what happened. Seems that the train for Eclipse Kepler was off, and my change would have to wait for the next train. And “we don’t have time to check it right now, but will get to this later”.

On the 12/12/2013, I was asked to sign a CLA (legal stuff transferring the code to the Eclipse Foundation). Cool! My code is finally going in!

Wrong. A new round of reviews started. More questions, why use this, why do that.

It’s been more than half a year since the commit. I don’t work every day on the Eclipse UI code and it took me two days just to get my whole environment back. And I’m being asked to do some more changes, to be consistent with other code. Sorry, but I have other things to do now. Maybe I’ll get to this in 6 months.

Published inProgramming

4 Comments

  1. Sorry to hear about your Eclipse-Experience. Eclipse is moving towards Enterprise and Systems Development (Planes, Cars, etc.), where they have stringent requirements regarding IP. This is an explanation, not an excuse – open source is supposed to be fun.

    • The IP is not the problem. The problem is the length of the process. Driving into the eclipse UI code takes time and effort. If you don’t do this every day, then going back to the code you wrote is like starting again. And this is a waste of someone’s time. It’s like the old saying (at least in spanish) “You give a hand and they take your arm”.

  2. I feel your pain, truly I do. But unlike a lot of smaller projects, that don’t have major corps donating $250K a pop and a gaggle of lawyers mucking up what should be a smooth process, eclipse does. The code eclipse ships needs to be clean or else they can be sued. Imagine if you got a RCP app from a vendor and then another vendor sued you because there was infringing material in the app. As for the release train, it takes a lot of focus to get all the subprojects on the right page and playing together to make sure that what is released in June, doesn’t blow up badly when plug-ins X and Y are both installed in the same product.

    • This is great. But what has happened is that Eclipse is required to compile with a JDK that is EOL, the code is “stale” because it is hard to make changes (check this example), and people just live with it. I have not done enough research on the subject, but it feels to me that most of the “core” eclipse code is maintained by a small number of persons, not only because this is their job, but because it is very hard to get into the club. But at the end this kills progress.

Leave a Reply to jastramCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Musings of a Strange Loop

Subscribe now to keep reading and get access to the full archive.

Continue reading