Where FindBugs Failed
SitePoint Java Newsletter VI (18-Nov-2016)
You’ll be surprised to hear that we also deliver this newsletter via email. To receive updates on our Java coverage every other Friday sign up here.
In the last newsletter I mentioned that the FindBugs community started a discussion about the project’s future and was entertaining the option of forking the project. And indeed this is what they ended up doing. I find this interesting not only for the project itself but also for the lessons we can learn from it.
FindBugs’ Struggle With Project Governance
First things first, let me start by introducing the fork before I try to draw some broader conclusions from what went on.
FindBugs Is Forked — Long Live SpotBugs
After a relatively short discussion some of FindBugs’ maintainers decided on November 5th that it was time to fork the project. Without much ado the name SpotBugs was chosen and a fork was created:
There was some hectic rebranding activity but other than that nothing much else happened. I stand by my point, unless there’s a fresh wave of committers the project is in serious risk of dying. (I was wrong in one point though, Java 9 compatibility seems to be no big issue.)
Why Fork?
A fork is a high-risk move. Anyone working on or with the project has to make a decision on which horse to bet. Maintainers, users, supporters, in short the entire community runs the risk of getting split in two for years to come. On top of that, the fork has to set up infrastructure like mailing lists, CI pipelines, artifact repositories, etc. and needs to come up with governance rules for the new project. That’s a lot of work and has some potential for conflicts as the new team forms. Unfortunately users don’t care about any of that — they want bugs fixed or features developed — something that might not happen in the forming weeks.
So what were the reasons for the SpotBugs folks to fork off? I’m no insider but I have been following the GitHub project and the mailing list for over a year and what I saw was… pretty much nothing. From that and the recent discussions, my own experience trying to contribute, and some good old contemplation I would give four reasons. In increasing importance:
- FindBugs does its job pretty well so there is not much urgency to improve — neither for maintainers nor for users.
- Some core committers moved on to other projects and only occasionally stopped by FindBugs.
- At the same time, contributing is comically complicated for newcomers. Not only is there an arcane configuration guide to follow (for example for the Eclipse plugin), the programming model itself is not particularly approachable either.
- The project’s founder holds all the keys — for example to make a release or update the project site — and was unresponsive for about a year.
Looking at that list it is no surprise that FindBugs showed little activity in recent time — since February 2015 there have been just over a hundred commits and little activity on issues and pull requests. But it was the last point that made the SpotBugs team fork. Sounds reasonable — who wants to work on a project where you can’t even make a release and the people who can do that ignore you?
A single point of failure, dwindling core committers, lacking newcomers — these are clear signs of a dying project. And I doubt that SpotBugs will fare much better unless it actively works on the underlying issues. That begs the questions what went wrong and what can be done to come back to life?
Project Governance
I believe in structures. I am convinced that everything we do has structure and shows organizational patterns. Often, they are implicit and not trivial to identify but that does not mean that they aren’t there and don’t shape the outcome. I also believe in making structures explicit and thus transparent. Have a list of who’s responsible for which microsercive, create a coding style and let the build system enforce it, draw high-level diagrams for important workflows in your system, and, in general, automate all the things — because how better to formalize something than to enshrine it in executable code?
So in the case of FindBugs / Spotbugs I think the project needs to work on its governance. Who can do what (reviews, commit rights, releases, project site updates)? Who makes decisions (deciding on features, changes to CI)? How can deadlocks and single points of failure be prevented? And most importantly: How does this change? What does a newcomer need to do to gain commit privileges and who decides that? What happens if a core committer leaves?
I already hear some of you say that this is way too much work and nobody needs all that to be discussed at length and then written down in excruciating detail. “That’s just politics.” “We’ll cross that bridge when we come to it.” Well, it’s not like these decisions need not be made frequently. Sticking your head in the sand won’t change that. And it is very much so that they can trigger long discussions. So why have them time and again, instead of deciding that, for the time being, that gal over here has the last call on CI disputes and these folks over there make final decisions on which feature to include?
Heck, this could be as simple as “These three decide all stand-offs by a majority vote without abstains.” Done. Just have something that people can look to in times of turmoil. Because you surely don’t want to fight it out under distress.
And if that chart shows the same name in all the spots, well, maybe the project needs to work on that next.
Onboarding
Another important aspect of open source projects is to make onboarding new developers as easy as possible. The more automation and documentation is in place, the easier it is for developers to start contributing and the less time the core team has to spend on supporting or vetting contributions. Ideally, hacking on the project is as easy as forking, cloning, maybe executing a script, and off you go! Every step a project adds will increase the chance of failure and people dropping out.
Having a clearly documented governance structure helps as well. It gives newcomers an idea what is expected of them, who to turn to with questions, and how their contributions are vetted and decided upon.
In Closing
Users don’t just rely on code — they also rely on the community creating it. As a project becomes more important it should strive to become more professional — technically as well as organizationally. So after setting up CI, why not put someone officially in charge of it?
By the way, Bill Pugh, FindBugs’ founder, showed up on HackerNews talked about “rebooting the FindBugs project” — let’s see…
What Else Is Going On?
Speaking of governance, the Java Community Process (JCP) elected a new executive committee (EC). Seven ratified seats, six elected seats, and two associate seats were up for election — these are the results:
- Ratified Seats:
Gemalto M2M GmbH, Goldman Sachs, MicroDoc, NXP Semiconductors N.V., SAP SE, Software AG and V2COM - Elected Seats:
Eclipse Foundation, London Java Community, Azul Systems, Twitter, Tomitribe and Hazelcast - Associate Seats:
Ivar Grimstad and Werner Keil
If you’re not sure how exactly the JCP works or what the EC does, let me recommend a post we published just this week:
Speaking of this week… it’s Open Source Week at SitePoint! Follow OSW on SitePoint or #OpenSourceWeek on Twitter to be part of it. Have your own free software project or story to share? Tweet about it with the same tag and let’s discuss.
Wrapping Things Up
Let me leave you with a couple of articles I think you might find interesting. On SitePoint:
Other:
- Oracle Presents First Proposal for Value Types Implementation
- Speaking Intelligently about “Java vs Node” Performance
- Trampolining: a practical guide for awesome Java Developers
- The Wrong Abstraction
- How We Make Money at Stack Overflow: 2016 Edition
I wish you a great time!
so long … Nicolai
PS: Don’t forget to subscribe. :)
