I Don’t Get It

By Robert Fischer | Published: February 5, 2010

When encountering a bug in an open source project, most Java people seem unwilling to either fix it themselves or pay the maintainer to fix it—they’d rather abandon the project or kludge their software painfully and repetitively. WTF?

No related posts.

This entry was posted in Open Source, Software Business and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • http://hamletdarcy.blogspot.com Hamlet D’Arcy

    In the past my problem has been that my organization would not let me rely on a personal or nightly build of a project. So when you need a workaround by the end of the week, waiting 2 months for the next release candidate of an OS project is not an option.

    … now go release JConch 1.2.

  • http://www.naildrivin5.com/blog Dave

    I’ve encountered this a few times. Sometimes, I’m trying to get things done, so I hack around the problem and then there’s not always time to go back and learn a new codebase to submit a patch.

    Further, having submitted a few patches to a maven plugin (a piece of software I cannot stand, but submitted anyway), it’s been months since I uploaded a freakin’ zip file to their JIRA and no movement.

    I also think compared to, say, Ruby, a lot of Java packages are very large and complex. If I find a bug in Spring or Hibernate, my chances of even navigating the codebase to find out where the problem is are nil. And Spring is actually pretty clean code; I mucked through JSCh and the maven release plugin and was HORRIFIED at how awful the code was.

    And then there’s the myriad build systems and spotty tests; One of the Castor devs asked me write a test or he wouldn’t accept my patch; my patch was to make his code actually compile. And their tests on trunk (and release tag) didn’t pass.

    Meanwhile, on github, I’ve submitted patches to things that I wrote and tested in less time than it took to find the svn link on Apache’s site. I’ve also incorporated others changes to my code (that they didn’t even submit). Granted these things are not as complex as Spring, but, well, maybe that’s a good thing?

  • http://www.naildrivin5.com/blog Dave

    @Hamlet D’Arcy in your case, I have imported the released version I’m using into our company’s svn repo and made changes I needed against that, then deployed THAT to our maven repo. It was painful, but worked.

  • http://twitter.com/RobertFischer Robert Fischer

    Argh. I’ve totally forgotten about JConch 1.2. Just released it. It’s now a Gradle-based build (I wanted to OSGi-ify the project and have a Maven repo).

  • http://spockframework.org Peter Niederwieser

    From my experience, most developers aren’t even willing to take the time to report a bug they encounter…

  • http://plasmasturm.org/ Aristotle Pagaltzis

    I agree with Peter – I actually tweeted the same observation just a few weeks ago. I got one response to that that didn’t satisfy me either.

    It’s not limited to Java either.

  • http://blog.james-carr.org James Carr

    Yeah… this has often surprised me as well. I’ve witnessed a team try to use some open source solution and give up because of a minor bug and go to a much more difficult to use proprietary solution (which amusingly had more critical bugs).

    I was also surprised when at my current client site they actually asked me spend a week working on fixing a bug in an open source project and submit a patch… that’s definitely the best attitude to have. :)

  • http://mcherm.com/ Michael Chermside

    For projects in ALL languages, the difficulty in getting a patch accepted is a genuine issue (and is difficult to solve). There is a sweet-spot of small, recent projects that accept patches easily. Older projects are often neglected (or abandoned) by their original authors, which makes accepting patches difficult. Larger projects necessarily set standards (like requiring unit tests or moderately complicated review processes, or certain coding standards) which not every patch will meet. The problem is not easily solved because these are inherent problems rather than just projects being obstinate.

    Meanwhile, Java programmers are probably worse because (1) many well-known open-source Java projects are large and corporately sponsored which makes it difficult to get them to accept patches, and (2) many Java programmers work in corporate environments where it is difficult to get “permission” to contribute to an open source project. Simply not being in the habit of doing so makes the practice less likely than with other languages.

  • Categories