In recent posts, I’ve been a bit critical with Open Source. But doing Open Source is a lot of fun. The publicity of feedback is thrilling and encouraging. And then, there’s the “I want to contribute” phenomenon. Those guys that are so thrilled with your wicked product that will change the world, they want to help. They want to participate. They want to contribute. They want instructions on how to do it. And then ……….. the big void. You’ll never hear from them again. Even if you ask them a couple of times, through private messages, etc. Even if you show them a couple of easy tickets that they could resolve first. Blank.
Who are they? Where did they come from? Where do they go? Are the real? Or robots?
Whoever they are, I find them amusing and refreshing. But now, back to work. Someone has to actually write the Open Source code.
Well, sometimes the “how to contribute” entry barrier seems like too much effort. Even working with Git branches might be a steep learning curve for developers not accustomed to working with Git (think most enterprise developers).
In my case, I wanted to send a patch to OpenJDK. Did you know that to become a contributor you need to sign a contract, scan it and email it to Oracle (http://openjdk.java.net/contribute/)?
I gave it up.
This isn’t so unusual in professional Open Source. Eclipse also has a CLA: http://www.eclipse.org/legal/CLA.php. So, if you really went through all the hassle of finding and fixing a bug in the JDK, why not just sign this little agreement with Oracle?
The correct licensing of user contributions is indeed very challenging. Most Open Source vendors neglect application of due diligence when it comes to maintaining copyright within their products. Without any express agreement, each contributor maintains the copyright of his contribution. If this isn’t managed correctly, larger Open Source products become pretty useless, commercially. This can be very bad also for users of Open Source software, as the software may die simply because of the legal impact eventually imposed on the vendor. (I’ll have to blog about this, some time)
With jOOQ 3.2’s moving towards dual licensing, I actually had to send out quite a few CLAs to past contributors, retrofitting copyright transfer agreements.
In other words, from an OSS vendor perspective, I prefer to accept contributions only from contributors that are ready to go “all the way”. There might be a slight grey area when it comes to minor patches, which might not be copyright-protectable (I am not a lawyer).
In this article, however, I’m slightly mocking those guys that disappear after realising the slightest effort they have to go through :-)
I think it’s morally wrong to say that it’s not ‘doing your due diligence’ to not ask for copyright assignment. Someone’s work is their own. They’re licensing it back to you under a copyleft agreement, not giving you ownership of it. If I had to assign my copyright back to the commercial vendor then they could just arbitrarily stop producing it as free software. That’s morally wrong, as it lets them exploit the community for bugfixes and then not contribute that code back to the community.
I’m not advocating copyright transfer per se, although we’re doing this in our case. I’m only advocating proper management of copyright in CLAs (or in licenses, such as the ASL 2.0). If an OSS license does not vest the right to sublicense contributions in any way, then the end user might have a legal problem because of some third-party contribution.
(Extremely late response but I got here via another article)
I’m one of those persons. Probably not on any project related to what you are doing but non the less. I too got enthusiastic about a certain project and used the project on a daily basis. As a software engineer (but not a hardcore technical person) I thought: I can contribute to the code base and help out. I might even benefit from the new functions and gain new insights and learn about new technologies while helping out!
So far so good. I was involved and willing. So I reached out and said I wanted to help. I signed up to help fix a mentored bug (so under supervision of an experienced developer) and started to setup my build environment.
That’s where I encountered a lot of problems. And they were all my own. I jumped into an extremely complicated project in a programming language I wasn’t fully fluent in, which had a build environment which was hard to setup, My OS wasn’t configured to the correct specs, I couldn’t get the emulator (which was used to test things) running on my machine and the list goes on. I tried hard to fix things, spend days on IRC getting help (and got a lot of help!) and never googled as much than as in those days.
But in the end I just wasn’t technically competent enough to actually help out and I made a mistake. So I apologized to the mentor and left. Now you know one story from a legion of faceless would-be contributors.
(I still am going to contribute but will choose a different path next time. Like mastering the language and its ecosystem first)
Thanks for sharing your thoughts. Well, that’s exactly what I thought :)
I’ve once read a very interesting article on the topic of why you should (or shouldn’t) contribute. Unfortunately, I don’t have a link anymore. The essence of the article was that you should have a clear incentive to contribute to a given project in particular. One such incentive is that you’re a user with an important stake. Another such incentive is that you really want to learn a given tech (e.g. SQL, or JavaFX, or …).
Just “wanting to help” is often a rather frustrating experience. Not because it’s hard per se. But because it’s hard and there is no clear incentive, no clear goal…
Besides, this really isn’t about Open Source, actually. You can contribute to commercial projects just as well by providing feedback (perhaps even source code, as in our case). Again, it is about incentive whether you want to “help” a vendor improve their product.
If someone is looking for article you might be talking about, I think I came here from there and the link is http://jvns.ca/blog/2014/04/26/i-dont-feel-guilty-about-not-contributing-to-open-source/