Monday, February 18, 2013

What can we(Eclipse community) learn from Libre Office?

Before reading further please watch "LibreOffice cleaning and re factoring a giant code base" from this year's FOSDEM conference. Note that reading this post without watching the video would put a lot of things out of context!

The one and single most obvious thing for me from the whole talk was "it's about the people". Watching it one will notice the amount of people that started contributing in there free time and how fast LibreOffice grows in number of contributors. As one that works almost entirely with Eclipse.org projects (especially Eclipse as an IDE) this made me ask a very basic question:

How did a pure end-user application managed to attract more developers to spend improving it in their free time than an IDE ?
 
I started to think about initial experience I had trying to improve various plugins and realized that we do fail entirely in welcoming new committers. Even after one has number of patches in, if one just opens a bug(gerrit review) and attaches his/her patch - nothing happens for months (even years!). Or the patch will comments why it can't happen now and nothing will happen for months/years again. Now I'll try to fight some of the most common myths used to explain the situation:
  • there is release pressing - this is seen for milestones, SR releases, etc. But there is always something pending and most of the time people start with so small contributions that they can hardly affect the whole release train. Potential contributors might be more happy if instead of saying it can't happen now and forget it, we do comment a week later once the M-build is out (this covers most of the calendar year) and work with the contributor to get his change in.
  • it gains us nothing - wrong! for at least two reasons: First: one of your users identified the need for it and cared to spend time to contribute it back, one could bet that he/she see it as important; Second: even if there will be no technical benefit immediately - that's one more contributor and this makes difference soon after that.
  • old versions depend on something that this patch changes - You know there is a reason for calling a version an old one. Don't hold the new development - we have the awesomeness of git - branching, cherry-picking and so on can hardly be easier. Old way of doing something belongs to maintenance branches. Here we come to catch 22 - there are not enough people to support two ways but we don't want new contributors too. New people need new things.
  • this part of the code is "tabu" - only blessed ones can touch it. Telling a potential contributor - "you're not smart enough" isn't it ? Well, I read it differently - if in my code there is something so sensible that I should be afraid is someone touches - it needs a fix (or ever rewrite?) as soon as possible so it can continue improving as normal part of the codebase. As long as someone starts spending his time on it of course.
  • it's not tested with other version of third party library - this is seen really often from my point so it's like a personal rant. If someone requests a dependency range to be bigger one can think that he tried it or that even a product using the version outside of the range is shipped. And this means nothing as the project can continue ship its preferred version but you can make the life of people depending on your code easier for no cost.
  • the contributor already ships a fork so he/she can continue do that - If one ships a fork and submits patches back it clearly means he doesn't want to do that but he is forced to do that because the project is not interested to grow in the area he needs.
If we want to grow as community members, everyone has to go through his projects bugzilla/gerrit see for pending patches or requests and make the easiest one come in the next release. Or we will soon get to the point where people will not even report bugs as they would not believe anyone will look at the bug opened and that would be a failure growing to disaster. Seeing even well respected people withing the community having to poke numbers of time for really simple patches to be applied makes me very sad as this is pure energy lost. One can fix few more bugs instead of rebasing patch 3 times and poking 5 times.
It's not too late for a change we need to just encourage people by accepting their changes or work with them till the change is in a good enough change. Just a bit more openness and trust to new contributors is needed. So do we actually want to grow the community?

14 comments:

Lars Vogel said...

Good post, now lets change the current situation.

Alexander Kurtakov said...

Well, the obvious question - "How?" still stands. This post was mainly provoked by the CBI work, where too many patched faced pure ignorance resulting in slowing down its acceptance significantly. The only way I can think of if complain more and louder. Poking for every patch just doesn't scale.

Lars Vogel said...

Why not start with something simple: https://bugs.eclipse.org/bugs/show_bug.cgi?id=400759

Vainolo said...

Great post. Definite problem. I think the "problem" is that much eclipse code is "owned" by "old" corporations which don't have a real open-source culture. Very hard to change their culture.

Robin said...

Good post. Some things which could be changed right now:

• No longer requiring non-committers to answer the "3 legal questions" for every change, see bug 381105.

• Providing Gerrit everywhere, including a Hudson job to verify the changes. Much better than attaching a patch to a bug.

Alexander Kurtakov said...

@Vainolo: I would not claim corporations entirely. I'm hired to work almost fulltime to work on eclipse+friends by one such. I've been doing it before that but now I do like ten times more per week. I do agree that not everyone manages to balance the needs of his employer and the projects he works on upstream but I do think it's up to people to do that.

Alexander Kurtakov said...

@Robin:
While I do agree that the process can be smoother one should never get legal questions easily. If there is one thing in my eyes that Eclipse foundation is outstanding it's the IP clearance policy. I've seen enough of a trouble with legal stuff to be happy that the foundation takes it seriously.
Fully agree that we can rely more on tooling for much of the manual stuff though. And it happens one by one to many projects.

Michael Scharf said...

I think one of the differences is that eclipse is an extensible, plug-in based system. There are lots of contracts encoded in APIs that clients rely on. In such an open system you have to be very careful when you change the APIs and this has been one of the strengths of eclipse. Eclipse is used as the foundation for many commercial and open source products.

LibreOffice, on the other hand is essentially a single monolithic application.

There are some changes in the pipe to make contribution to eclipse simpler but we have to take into account the different nature of the two projects.

Alexander Kurtakov said...

Well, at least for me "accepting contributions" != "breaking API". Very few of the patches staying in Bugzilla for months/years are breaking API.

Michael Scharf said...

> "accepting contributions" != "breaking API"

I would agree. And I have been in that situation that some bug fixes have not been applied, because there were no active committers on the project. It took 3 years until someone looked into the bugs and finally applied the fixes.

I was more reacting to the style "anyone can change anything and if something is broken, then we fix it" in the presentation.

Making it easier to contribute should clearly be a goal for the eclipse community.

Alexander Kurtakov said...

"anyone can change anything and if something is broken, then we fix it" will force people to get proactive and step in to test and help improve the platform instead of relying on platform maintains and improves by itself. Considering the current amount of contributions I would even say that such approach would be beneficial to regain some momentum.

drsafetyman said...

Checkout this article [http://www.infoq.com/articles/Gerrit-jenkins-hudson] or webinar [http://visit.collab.net/2013Q1WebinarGoAgilewithGitPt3HandsOnLabwithGerritJenkins_RegLP.html] describing Feature Branching with automated pull requests using Git, Jenkins, and Gerrit.

drsafetyman said...

Article [http://www.infoq.com/articles/Gerrit-jenkins-hudson]

Webinar [http://visit.collab.net/2013Q1WebinarGoAgilewithGitPt3HandsOnLabwithGerritJenkins_RegLP.html]

drsafetyman said...

Let's try this linking thing one more time!

Article

Webinar