SIDEBAR
»
S
I
D
E
B
A
R
«
“Participate in community!” they said…
December 11th, 2009 by Eugene Ostroukhov

I see a lot of discussion in the blogs on how to invite new developers to participate. They all are talking about people being reluctant to do development, making the eclipse.org site interface more inviting – but really, is this the biggest problem? I wonder, does anybody think obscure location of the CVS URL would really stop anybody from trying to enhance the favorite framework?

Consider this (the ones that I remember):

Bug 287887 – I haven’t seen response like “why would anybody want this” or else. The patch was submitted 3 months ago.

Bug 155479 – several commercial projects would like to see it. Patch was submitted in April.

Bug 166906 – pretty irritating bug. The patch was submitted four years ago.

Note – these are patches to make Eclipse better from the end-user POV. It’s not the patches to make Eclipse frameworks more open for extension so we can build better products on top of it – I’m pretty sure that most commercial developers know that there is next to no chance to get such change into Eclipse.org.

The result is quite simple. I joined a new company recently and from the start I say – do not expect the Eclipse.org to cooperate. We need to consider a way to branch projects we use – before we reach the point it is not possible to deliver proper product to our customers because the framework was not designed to support something.

I believe there should be a strict policy in Eclipse.org for handling patches – i.e. the projects should commit to responding for the patch in 2 weeks or one month – and either describe what’s wrong or to incorporate the patch into main repository. Otherwise there will be many Eclipses – Git makes it really simple.

And I’m not mentioning this: 262846 – pure enhancement to make simple API for the popular feature. I submitted this one in February – and I missed some Eclipse.org deadline. The result? Even in the best-case scenario I won’t be able to use this in my commercial product till Summer 2010 – 1.5 years. That’s if we don’t consider that the chances of this bug being committed are still slim. So why bother? 1.5 years is a long time.


19 Responses  
  • Thomas Hallgren writes:
    December 11th, 20093:19 pmat

    I think that in general, the response to submitted bugs is exceptionally good at Eclipse.org. At least compared to most other open source communities where I’ve been involved. There are exceptions to the rule of course, and I agree that bugs that even has patches attached to them most certainly deserves a response. Not so sure it’s a good idea to try and enforce it though.

    It would be easy to ensure timely responses if the bug-submitters were willing to pay a support contract but chances are high that the added bureaucracy that comes with that just makes things worse. Compare the support you get from Eclipse.org with what you get from a commercial vendor like IBM, Oracle, Microsoft, etc. I don’t think anyone would like us to switch to a model more similar to theirs.

    • David Carver writes:
      December 11th, 20094:22 pmat

      Thomas the response varies greatly by project. Even though we do a pretty good job, we as committers can do a better job. At times we need to put the communities needs above our own product needs. Bugs with patches should be addressed in some way, even with a note saying thanks..but here are the reasons we can’t do it. Communication with your community is key to keeping them intersted, and this has to happen in a timely fashion. I also think that projects should consider shorter release schedules. Mylyn is great for this, they release once a quarter, which provides functionality sooner, rather than later.

    • Eugene Ostroukhov writes:
      December 11th, 20094:34 pmat

      I am not talking about all submitted bugs – only about ones with the patch. I understand that it does not make sense to fix anything the users will submit. I’m talking about the patches – about the people who want to contribute, not just use. Users can find commercial distribution, can find company who would fix something for a fee. But it is next to impossible to push your patch into the CVS. I.e. imagine small commercial vendor that can’t afford becoming a member and to fund committer. Currently they are almost forced to work with some company that has committers and can get the code to repository. Or just maintain custom branch of the code…

  • Ed Merks writes:
    December 11th, 20094:31 pmat

    It seems to me most of the bugzillas you cite have been reasonably handled. I get this feeling of “complaints about the salad”…

    As for strict policies, keep in mind that those who provide free things are under absolutely no obligation to meet the arbitrary demands of others. Once money changes hands, then you’ll be in a position to specify policies and enforce them.

    • Eugene Ostroukhov writes:
      December 11th, 20094:45 pmat
      1. “Reasonably handled” = hanging in the air for months if not years? I am not talking about bugs but patches. I understand that no one is obliged to fix anything user reported. But I do believe that if declared goal is community involvement – then patches should be handled on the first place. Instead of site facelifting efforts.
      2. “Once money changes hands, then you’ll be in a position to specify policies and enforce them.” Right. So much for “meritocracy” and other words from marketing department. Either you invest into committer or contract one of the companies that has committers or you will never get your fix into the repository.

      Let me reiterate – I’m not talking about fixing bugs. I’m talking about letting others fix them – by investing their time and effort instead of money.

  • Curtis Windatt writes:
    December 11th, 20095:20 pmat

    It’s great when contributors take the time and effort to provide patches, but it takes a significant amount of committer time to review the work. The majority of patches I see are one off contributions by individuals who do not have, and are not trying to, gain a full understanding of the component. Instead the patches simply solve the one problem they are having, with no consideration for how the change affects the rest of the component. Bugs with patches should (and I would argue, do) get more attention. However, it is unreasonable to demand that committers, who have to make their employer’s interests a priority, spend the time to review every patch provided by the community.

    • Eugene Ostroukhov writes:
      December 11th, 20095:28 pmat

      I see problem with patches as a concrete wall between eclipse.org and community. There is no incentive to submit patches – the chances of the patch to be accepted are so low.

      I am not telling about my personal experience – I created this blog entry after lengthy discussion with the developers from other company on how to handle branches of the eclipse.org projects.

  • Casey Marshall writes:
    December 11th, 20097:21 pmat

    I appreciate the difficulty of accepting patches while simultaneously maintaining a project and developing new features or taking it in a new direction. Not an easy task. Project leaders have to triage. They’re busy, brilliant people whom I hold in the highest regard.

    However as one who builds with Eclipse, waiting 1.5 years for a feature or bugfix is completely unacceptable. This is why I think DVCS like git have the potential to absolutely transform the Eclipse ecosystem. Our patches won’t just sit scattered in Bugzilla tickets gathering dust if we can cherry-pick them into our products.

    I’m not advocating total anarchy. We desperately need project owners to make the final decision for what is most appropriate, pick the best of the best, keep coding standards, API compatibility, IP compliance, etc. But I think we also need some seething DVCS chaos to eliminate some of the bottleneck.

    This chaos involves risk. Some of us (or our employers) will be very conservative, and only work from those major baseline releases. They are the ones who should be heavily funding those baselines. Others of us are lean & mean startups, comfortable with tearing through the sources, willing to sacrifice some API changes in the next major release to get a feature out today… We may not have deep pockets, but we can bring a marketplace of ideas, if there’s somewhere to share them.

    • Eugene Ostroukhov writes:
      December 11th, 20097:45 pmat

      I’m afraid easier branching will mean less sharing between projects…

  • Lars Vogel writes:
    December 11th, 20098:02 pmat

    My personal experience with providing bugs and patches is completely positive. I’m always surprised how fast the Eclipse Committers react and about the quality of the feedback.

    • Donald Smith writes:
      December 11th, 20098:47 pmat

      Just ran a few bugzilla queries and easily found 1000’s of cases that counter the three posted here.

  • Alexander Smirnoff writes:
    December 11th, 20099:14 pmat

    I agree with Eugene on this point. Being a long follower of Eclipse and developer of the commercial products based on Eclipse, just only makes me a “friend” (or whatever it means when you donate the money) of Eclipse and far away from the feeling myself a contributor or being interested feeling like one, even though I filed a bugs (with patches).

    I see the patch I have submitted few months ago lying dead (bug is tiny and obvious in PDE) without any response or QA assignment and that is exactly what makes me less interesting to submit something similar next time.

    I also understand that the voices in open community are heard based on meritocracy principle. But what it is has to do with QA? If the Foundation is a “trade association” or whatever commercial entity it may call itself, it makes really lousy work with QA of it’s main product.

    I would love to see higher standards on bug tracking and resolutions. This would help not only the product, but also myself feeling more likely to contribute next time. Hope I’ll be heard.

  • John Arthorne writes:
    December 12th, 200912:39 amat

    I agree that bugs with patches don’t get enough attention, but unfortunately there just aren’t enough committers to handle them all. There are >1000 open bugs with patches in the Eclipse top-level project (http://tinyurl.com/eclipseopenwithpatch), and only a small number of active committers able to commit them. However, very many patches do get a applied, so it’s hard to draw any interesting conclusion from a small sample. You can easily browse the Eclipse project IP log to see a list of contributed patches that were actually applied in 3.5:

    http://www.eclipse.org/eclipse/development/project-log-files/eclipseproject35log.html

  • Elias Volanakis writes:
    December 12th, 20092:06 amat

    I think Eugene has a valid point. In my experience most projects are good in processing patches, but a few are bad.

    The problem from my POV is that for outsiders it is impossible to tell before hand what to expect from a project and what communication channels exist to move bug resolution forward:

    • What is the average time to resolve a bug?
    • How much re-work / additional work is expected?
    • How long should I wait before “nagging”?
    • This issue is stuck. Who can I PAY to resolve bugs or process patches right now ?

    Some quick ideas:

    • Projects should publish information about how to resolve bugs, contract support, average bug resolution times
    • From my POV it’s better to say this needs work, would you like to contract me or somebody to do this, instead of just ignoring the issue.
    • A bugzilla field for attaching a “bounty” to bugs – as in I would like to pay X dollars to have this fixed.
    • A directory of committers than can be contracted to fix bugs quickly. It is not apparent to outsiders who is available for this type of work.
  • Chris Aniszczyk writes:
    December 12th, 20098:53 pmat

    This is completely the wrong attitude to take in my opinion. I think in the majority of the cases, patches have been accepted and applied. Have all? No, but this is a fact of any environment that has a set of limited resources.

    If certain open source components are critical to your business, how about considering investing some resources and stating your interest in participating in the project? The quickest path to ensure your work gets into the projects you care about is to become a committer.

    For patches that linger, feel free to bug the committers more. Nagging surprisingly works in most cases.

    In the end, just like in life, it’s all about relationships. If committers trust you and there’s a relationship there, your patches will get in faster. On certain core projects, committers have to be very careful to preserve API and behavior… which many contributors may not care about.

    In regards to the DVCS note, it will definitely make it easier for people to maintain their own forks and contribute their fixes back. Part of the problem of currently maintaining your fork is the maintenance of patches and keeping up with Eclipse as it evolves. Git makes this much easier than it currently is with CVS and SVN. This is why I’m pushing big to enable Git at Eclipse. On top of that, we may want to consider having something where companies can “publicly” fork certain Eclipse projects so people are aware of it.

    On a side note Eugene, if the Symbian Foundation would like to be more involved at Eclipse, there are ways to make that happen :)

    • Eugene Ostroukhov writes:
      December 12th, 20099:12 pmat

      Symbian Foundation is really interested in working with Eclipse.org. And I’m really glad I will be part of these efforts.

    • Eugene Ostroukhov writes:
      December 12th, 20099:20 pmat

      Please note the disclamer in the sidebar – “Any opinions expressed here are my views only, and do not necessarily reflect the views of my employer or their affiliates.” :) I’m just a newcomer of the Symbian Foundation so this opinion is coming from my past work. But the problem is really that I’m bringing this prejudice with me. Helping Eclipse is a great thing – if you have resources to share. I believe the greatest thing about eclipse.org and open source in general is that it enables small companies create great software that may compete with the solution from the corporations. It is really hard to have developer part-time committing to Eclipse.org when the product is built by a team of two.

      And really, this post is not about “we can’t get our changes into central repository”. It is about “people don’t participate because their patches are ignored and facelifting the site won’t help”.

  • When you’re right, there is no middle ground « Dark Views writes:
    January 15th, 20108:24 pmat

    […] bills. I nodded like everyone else. And we talked about Eugene Ostroukhov and his complaint ““Participate in community!” they said…“. And I immediately saw a parallel in my own history. I had a similar, painful experience […]

  • Looking back and into the future – Part I « Tomsondev Blog writes:
    February 28th, 20103:46 pmat

    […] the time to work on 3.x (when reading blogs like this from Eugene Ostroukhov my willingness to invest spare time on it is equal to 0) TOTAL […]


»  Substance:WordPress   »  Style:Ahren Ahimsa