
FindBugs project in its current form  is dead - fanalin
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html
======
billpugh
FindBugs isn’t dead (although my participation had been in hibernation for a
while).

I’ve been juggling far too many projects, but I’m now working to move FindBugs
back into the active rotation.

I also want announce I'll be working with GrammaTech as part of the Swamp
Project, and they will be helping with rebooting the FindBugs project. This
has been in the works for a long time (almost a year), and although I’ve known
that GrammaTech was likely to win an award, this hasn’t been official and
something I could talk about until recently. Was hoping to have something a
little more concrete to talk about as far as that goes; but I don’t yet have
the information I wanted to share.

Thanks to all the FindBugs fans and supporters who lobbied for me to return to
active maintenance of FindBugs. Give me a week to get up to speed on current
project needs.

Bill Pugh

~~~
unreal37
It's still not a good sign that it took this level of public attention to get
you to reply to the active community on their urgent needs.

~~~
dmuth
^ this. There is absolutely no reason to not be answering emails, even if to
say, "I'm really swamped, and need help."

I don't mean to denigrate you, but I must be candid here: hoarding admin
rights so that only you have them and no one else can get any work done is
simply not acceptable in a team environment.

Going forward, I would recommend taking a look through other projects you may
be involved with, and make sure that you are not the only person with admin
access. If nothing else, it would increase the "bus factor" to greater than 1:
[https://en.wikipedia.org/wiki/Bus_factor](https://en.wikipedia.org/wiki/Bus_factor)

Good luck.

~~~
danielheath
There is absolutely no reason to expect volunteers to owe you their time or
responses.

I don't mean to denigrate you, but I must be candid here: demanding work from
others without putting in the hard yards yourself is simply not acceptable.

Going forward, I would recommend taking a look at your written communication,
and make sure that you are being fair and kind.

Good luck.

~~~
enraged_camel
He didn't demand "work", he simply pointed out that hibernating or abandoning
a project many people have come to rely on without arranging for others to (at
least temporarily) take over is irresponsible and causes a lot of frustration.

~~~
lukeschlather
Answering emails is work. It's also often a lot harder than it sounds at first
blush.

~~~
enraged_camel
Setting up auto-reply takes 10 minutes. All modern email clients allow
creating auto-reply rules based on who the email is from or the words the
subject line or body contain.

"Thank you for your email. This is an automated reply to let you know that
active development of this project is currently on hold. If you have any
questions, please email bob@project.com, who is the current maintainer."

That's it.

------
gaul
Google error-prone is a good alternative to FindBugs:

[https://github.com/google/error-prone](https://github.com/google/error-prone)

[http://errorprone.info/bugpatterns](http://errorprone.info/bugpatterns)

Pros:

    
    
      * has faster cycle times and integrates into compilation workflow
      * emits fewer false positives
      * active maintainers fix issues
      * releases several times per year
    

Cons:

    
    
      * FindBugs has a greater breadth of checks
      * current error-prone releases only work with Java 8

~~~
Seol
Also, error-prone works in a fundamentally different way to FindBugs: error-
prone is a compiler plugin, whereas Findbugs is an after-the-fact static
analyser. This means, for example, you can include dependencies on the
codebase you're analysing in your findbugs checks, but not in error-prone.

This turns out to be really quite relevant if you're building domain-specific
static analysis checks, as opposed to just running standard analyses.

~~~
needusername
> error-prone is a compiler plugin

Can you provide more information on how this is achieved? As far as I know
there is no official, supported, portable API for Java compilers. The only
thing I'm aware of is APT and anything beyond that would require significant
rearchitecture of the existing compilers.

~~~
Seol
Technically, it's not a compiler plugin - it actually replaces javac by
extending JavaCompiler, wrapping it and applying additional verifications
without altering the output. Effectively it's introducing its own API for
compiler plugins, with those being the checks, very much akin to APT.

See [https://github.com/google/error-
prone/blob/master/core/src/m...](https://github.com/google/error-
prone/blob/master/core/src/main/java/com/google/errorprone/BaseErrorProneJavaCompiler.java)
for the entry-point.

I'm very close to getting out of my depth here though :)

~~~
needusername
This is not close to a plugin. I don't see why the term plugin is used here.
This is misleading people into believing error-prone is using a supported API.

I also don't see how it is "very much akin to APT". APT is an API where the A
stands for abstract and the I stands for interface. APT therefore is portable
across compilers and supported. error-prone seems to be tied to the current
implementation of javac.

It is as if words don't have a meaning anymore, all that matters is how you
feel.

I am very reluctant to use such a tool because to me it looks likely that it's
going to have similar problems to tools by Google relying on the
implementation internal APIs in the past (eg. Android or GAE/J). Supporting
new versions of Java is going to require serious amounts of effort and
therefore going to be very late if it happens at all.

~~~
Afty
The standard annotation processing APIs don't provide enough information to do
the analyses we want to do, so we do hook into javac internals.

It does require a lot of effort to keep up with OpenJDK updates, but that's my
team's job, and we have to do the work anyway to keep Error Prone running
inside Google. We tie Error Prone to a specific version of javac, which
matches the one we are currently using inside Google
([https://github.com/google/error-prone-
javac](https://github.com/google/error-prone-javac)), so we don't have to
support multiple different internal APIs. We are currently using a version of
javac 9 from about a year ago, and we're planning a bump to something close to
head maybe in Q1.

Eclipse integration would be a pain but would look a lot like what the Checker
Framework does.

~~~
needusername
This is all fine and good if you're a Google internal user who gets support
form your team. Things are a bit different if you're a user from outside of
Google.

------
mkobit
Further on in the email chain, it looks like there is momentum for hard
forking under another project named 'SpotBugs' [1, 2]. I hope to see the
project live on as it has been useful. Other tools like Google's Error Prone
and IntelliJ's inspection toolset are awesome, and FindBugs is complimentary
to them.

[1] [https://mailman.cs.umd.edu/pipermail/findbugs-
discuss/2016-N...](https://mailman.cs.umd.edu/pipermail/findbugs-
discuss/2016-November/004330.html)

[2]
[https://github.com/spotbugs/spotbugs](https://github.com/spotbugs/spotbugs)

~~~
TD-Linux
Side note: "hard fork" has a special meaning for Bitcoin and derivatives, but
no meaning for a software fork. I've seen that phrase used several times in
the comments though - is this a new trend?

~~~
mkobit
I'm not familiar with Block chain terminology, so I was not aware of the
collision.

A previous response in the thread [1] also contains "hard fork", which is
probably why I and possibly others have repeated it here.

It could be a trend, but my differentiation (here at least) is that a "hard"
fork means that the maintainers themselves are splitting from the original
project while also forking the original code base.

It would probably make more sense to just call it a "fork" :).

[1]: [https://mailman.cs.umd.edu/pipermail/findbugs-
discuss/2016-N...](https://mailman.cs.umd.edu/pipermail/findbugs-
discuss/2016-November/004329.html)

------
sam_lowry_
Coverity makes a shitload of money off FindBugs. It's annoying they don't
contribute back while my organisation pays their most expensive license.

~~~
achou
Um, Coverity contributes a lot to the open source community through Scan[1].

While Coverity does incorporate Findbugs results, it also has its own analyzer
that does much more interprocedural analysis and tends to be tuned better for
fewer false positives and more accurate error messages. Historically at least,
part of the reason for incorporating Findbugs was to make it easier to
directly compare what Findbugs found with what Coverity's analyzer found.
Because every customer wanted to know that.

I have no idea of current figures but historically Java was not a big business
for Coverity. Other vendors had much more Java business (and incidentally also
incorporated Findbugs results).

Finally, as you can see from the message the Findbugs leadership does not seem
unified and easy to collaborate with.

So forgive me but I find your comment and its tone a bit unfair.

[1] [https://scan.coverity.com](https://scan.coverity.com)

~~~
lowry
Coverity Scan is a marketing tool. As for FindBugs integration... The majority
of Coverity issues I deal with are labelled as FindBugs issues.

~~~
zodiac
I'm curious, why don't you run findbugs directly rather than (I presume)
paying Coverity?

~~~
lowry
I would, but the business still pays Coverity and I have to regularly check
Coverity reports.

Simple subordination.

------
mabbo
What a shame. I work for a fortune 100 company that enables findbugs on all
projects by default. I cannot fathom how many serious issues it's prevented.

~~~
timruffles
Could you ask the company to help out?

~~~
mabbo
Yeah, they aren't really big on the 'contributing to open source' thing.

~~~
mikecb
They're about to lose a valuable tool that they'll have to pay money to
replace anyhow. It's not hard to make a business case for.

~~~
analognoise
You're assuming they're rational actors. They aren't - at some places (big
defense) it's easier to get tens of thousands of dollars of software and
compute resources than it is to get OSS approved.

------
pm215
If you're an open source project that's expanded to more than a few people,
it's worth going through and making a list of all the various "admin" items
your project has accumulated (website? domain name? github? bug tracker?
mailing lists? etc) and making sure that for each of them there are at least
two people with admin rights and that how to add/remove admins is documented.
People do drift away from open source projects (or get run over by the
proverbial bus) and single points of failure can make things very awkward.

------
nickpsecurity
A million downloads, commercial deployments by 3rd parties, and basically no
contributions coming in. The status quo of the open-source model. They should
start selling it to companies to finance their own work on it. Or encourage
others interested in static analysis to do the same.

~~~
pjmlp
This is what kind of changed my view on FOSS as a way to make a living.

In all the companies I have worked through my career thus far, not a single
one has contributed back in any form to the pile of FOSS libraries that they
were using.

~~~
jknoepfler
As with insistence on code quality, useful and careful testing, infrastructure
automation, and good design and review practices, I think the culture of
giving back has to come from developers who care about their professional
ethos.

My team at EvilCorp contributes fixes to several open-source libraries. The
reason this happens, though, is that two of our stronger devs said "the
correct thing to do is to take the time to get these fixes into mainline,"
which they did. The answer to the question of "why" we do it isn't "because it
increases our team velocity," but because we're software engineers, and that's
what good software engineers do whenever possible.

~~~
pjmlp
> I think the culture of giving back has to come from developers who care
> about their professional ethos.

On my case that would be the path to be fired.

In none of the companies I worked for, doing that would work without going
though legal and all the necessary layers to green light it.

~~~
pm215
You definitely can't skip the step of getting managerial and legal signoff
(and no sensible open source project wants a patch that the developer doesn't
have the right and authorisation from the employer to contribute). But in
better companies it is possible to make that case and get the agreement.

------
aardvark179
That's a real shame as I've found FindBugs to be much clearer in its output
than many of the commercial offerings (some of which simply wrap FB's output).

I hope they can get a new project off the ground and can start rebuilding.
We're approaching a time where JVM static analysis tools are going to have to
start making some big changes to support upcoming features, and it will be a
pity if some version of FB or a successor isn't there.

~~~
taeric
Coverity was rather impressive. It did merely wrap a subset of FindBugs
errors, but that was mainly to show that they were adding to what FindBugs
could do. The points of the code that they spotted were always much more
clearly explained for why they were problems.

------
CraigJPerry
Sonar, or SonarQube as it's called now, does need more initial config than
findbugs. To get a liveable configuration anyway.

Once setup though, the quality of analysis is absolutely outstanding.

~~~
masklinn
I guess it depends on the language, or possibly the setup, the python projects
I've been part of using SonarQube its reports were worthless busywork (e.g.
requirements of docstrings to every method, resolved by adding """ fuck off
sonar """ everywhere).

~~~
michaelt
At least with Java, SonarQube checkers can be individually turned on and off
at the project level. Isn't that possible with Python?

~~~
tom9729
It's possible with all of the languages. Perhaps static analysis is just
difficult with Python?

~~~
icebraining
Static analysis is certainly difficult in Python, but you can still do a lot
better than "missing docstring".

------
smoyer
I'd like to echo the sentiment of everyone else here that would be sad to see
the death of Findbugs - When the draft of JSR-305 was released, I was hoping
to see an array of tools that would almost be "standardized" around the static
code analysis annotations. I'm working on reviving that JSR and will see if I
can chat with Dr. Pugh as well.

------
justin66
I don't have a Twitter account, so maybe I'm missing something about the
difficulty here. But the author spent paragraphs describing how the fate of
this major thing is largely in the hands of Bill Pugh, he can't reach Bill
Pugh via email, maybe his email is expired, etc. etc. can someone please help
contact him via phone or twitter or whatever?

Why not just create a twitter account and do it yourself? WTF?

edit: presumably one of the downvoters is working right this minute to contact
Bill Pugh via Twitter and put him in touch with the author, because that
totally makes sense

~~~
raphman
Apparently, some people have been trying this (but only after the e-mail was
sent):

[https://twitter.com/search?f=tweets&vertical=default&q=%22%4...](https://twitter.com/search?f=tweets&vertical=default&q=%22%40wpugh%22&src=typd)

~~~
Macha
Not the first attempt, see this one august 15:
[https://mobile.twitter.com/HaydenPJones/status/7652868811814...](https://mobile.twitter.com/HaydenPJones/status/765286881181466626)

------
dangoldin
What a shame - it caught a few bugs in my code and has definitely made me a
better programmer.

One of the reasons is that the code is hard to maintain with most open source
contributions being small improvements. How have other open source projects
handled large scale refactors? Is it as simple as someone creating something
new from scratch and then duplicating functionality? Are there examples of
large open source projects that have had ground up rewrites?

~~~
stefs
> Are there examples of large open source projects that have had ground up
> rewrites?

well, netscape navigator turned into firefox. it cost them dearly (in terms of
market share), but there wasn't much of an alternative (joel spolsky might not
agree on that).

~~~
wtracy
Arguably two major rewrites: one early in the life of the Mozilla project,
when the FOSS community deemed the original Netscape code dump to be nearly
unmaintainable, and the second during the creation of Firefox itself (although
that was mostly a re-do of the browser chrome, while the core was left
untouched).

~~~
batbomb
It was Phoenix -> Firebird -> Firefox.

~~~
icebraining
Those were just name changes, the rewrites were Netscape → Mozilla Suite →
Phoenix/Firebird/Firefox.

------
riffraff
This is sad, I've enjoyed using findbugs when I was doing java. Fingers
crossed that this can lead to a rebirth of the project.

------
jknoepfler
For those looking for an alternative, I've had reasonable success with PMD:
[https://pmd.github.io/](https://pmd.github.io/)

~~~
80x25
PMD and FindBugs really complement each other:

[http://stackoverflow.com/questions/4297014/what-are-the-
diff...](http://stackoverflow.com/questions/4297014/what-are-the-differences-
between-pmd-and-findbugs)

------
nstj
I just had a quick look at the repo and I'm not particularly familiar with the
project but what's the issue with just doing a hard fork if there are enough
people who want this to keep going?

~~~
rincebrain
This is addressed in the link, but basically, the extant codebase is extremely
crufty, to the point that a rewrite would be the suggested course forward
(and, indeed, the other formerly-active major contributor started his own
clean codebase to implement similar functionality).

So one of the two active contributors left to start his own rewrite of the
project, and this post is the other active contributor saying he definitely
doesn't have enough time to keep doing this on his own.

If there's no association with the old project's name or references from it to
the new project, then whatever came from it would probably not use the name
"FindBugs", and either way, the original project ends up dead.

------
sdegutis
Interestingly, the spirit of the FindBugs project lives on in the development
of languages like Rust and Swift, considering the purpose of the FindBugs
project is to fix inherent flaws in Java, e.g. not having a way to determine
whether something will be null, or not telling you whether you checked whether
something will be null at runtime, etc.

~~~
scarmig
Static analysis is not about fixing the "inherent flaws in Java." Findbugs
does help mitigate issues from language design, but most things that it does
would be silly to try to figure out a way to bake into the language itself.

[http://findbugs.sourceforge.net/bugDescriptions.html](http://findbugs.sourceforge.net/bugDescriptions.html)

