[FB-Discuss] Project status
nipa at codefx.org
Wed Nov 2 09:01:39 EDT 2016
-----BEGIN PGP SIGNED MESSAGE-----
Because it worked so well last time, I'll continue to play 😈's
advocate... And what Tagir and Andrey wrote pretty much confirms my
I was a fervent user of FindBugs and even tried to contribute. From
what little I saw I can definitely say that, yes, the code is neither
easy nor pleasant to work with.
And even I got the impression that BCEL is a fickle dependency. I have
to admit that I don't exactly know how it does its job but since it's
pretty low level I would bet a decent amount of money that it doesn't
even work on Java 9. (This should be checked, though!) More questions
ensue, which the maintainers can probably answer:
* Wasn't FindBugs using a BCEL fork?
* Is it a somewhat current version?
* Could the project jump to the most current once a Java 9 compatible
version comes out?
Taken together with the problems Tagir described for Java 8, chances
are FindBugs will soon lag six years behind the JDK with the next Java
version (10, maybe specialization and/or value types) breaking even
more assumptions than the current - particularly on a bytecode level.
To me this looks like a huge amount of technical debt on the shoulders
of, err, nobody? And on top of that comes trying to revive or fork an
entire project, which takes a considerable energy of its own.
So unless a significant number of devs (e.g. those arguing for the
continuation of FindBugs) step up to the plate and commit to working a
couple of hours a week on this, the project is dead by the plain fact
that there is a _huge_ disparity between what can and what needs to be
All that being said, I'm not usually Negative Nanny - it's just how I
see things in this particular instance. Forgive me. :)
so long ... Nicolai
On 02.11.2016 11:05, Andrey Loskutov wrote:
> Hi all,
> TL;DR: I'm really sorry to say, but FindBugs project in its current
> form is dead.
> Longer explanation follows.
> Current project setup is:
> 1) On the plus side, we have two committers with push rights to
> the github repo, however one from this two (Tagir) is not active
> anymore for the project and second one (me) has no free time to
> work on the project. That's however all about the good things...
> 2) Only the project leader Bill Pugh has admin rights for the
> project web page and the github project group and page. We cannot
> deploy any website update, we can't add new project members, we
> can't manage code access rights, we can't publish releases to the
> well known update sites without his help. Without him, we have no
> admin rights to anything, we can only push to the repository.
> 3) It looks like Bill Pugh is not interested in the FindBugs
> project anymore, and we can't reach them. I say "it looks like"
> because we requested his help for the project many times (via
> direct mails, postings to the list and to the github issues) but
> haven't received any sign of life from him since a year. We know
> that he is active elsewhere (https://twitter.com/wpugh). A week ago
> I've sent another mail to Bill (and CC to the
> findbugs-core at lists.sourceforge.net mailing list) asking him about
> the current project state - with no answer so far. You can read my
> mail in the attachment. IMHO no answer to this mail was the answer
> enough. Either Bill has completely lost access to his old mail
> account (which is possible too) or he is ignoring me or the
> project (which is more likely).
> If someone has a possibility to contact him in some way
> (twitter/mail/phone/whatever) and point him to the discussion on
> this list - please do so!
> Without Bill Pugh FindBugs project is headless and effectively
> *finally* dead. It is not the *only* reason for the project to be
> dead, but a bigger one, and the last one.
> The other major reasons for the FindBugs current bad state:
> 1) The code is very complex, has "organically grown" over a decade,
> is not documented and has poor public interfaces. Most of the code
> consists of the very low level bytecode related stuff, tightly
> coupled with the ancient BCEL library, which doesn't scale and is
> not multi-thread safe. No one enjoys maintaining this code, at
> least not me. I see no future for FindBugs with the BCEL approach,
> and see no way to get rid of it without investing lot of effort,
> and without breaking every detector and possibly many 3rd party
> tools. This is the biggest issue we have with FindBugs today, and
> most likely the root cause for all the evil. This code can't be
> fixed, it must be rewritten.
> 2) Because the code is as it is, there are not so many people
> willing to contribute. We see some pull requests on github, but
> most of them are smaller fixes or enhancements (many thanks to you
> guys, and sorry I have no time to review and test all of them!).
> Those who were willing and able to contribute leaved the project
> one by one. At last, we had Tagir contributed lot of things (many
> thanks!), but since he left us for his own project
> (https://github.com/amaembo/huntbugs) we saw no major code
> contributions anymore. BTW the fact that he left the project is
> also a sign that the project is in a very bad shape - it was easier
> for him to write the code from scratch as to continue supporting
> FindBugs. Currently I'm the last committer left on the project, and
> I'm not really active because lack of the free time. We clearly
> failed to build a contributors community.
> 3) We have *zero* support from organizations. There are no
> companies investing into the project in any way (neither via code
> patches or testing, nor via spending developers time for the
> project), although I know there are companies using FindBugs in
> their commercial products, for example SonarSource and Coverity,
> and of course there are many companies and projects just using
> FindBugs in their build processes.
> Add to this the project leader ignoring all communication with the
> project and you will agree with me that FindBugs today is a
> headless "zombie" project without future.
> However, FindBugs is still useful, even in its current state, and
> it will be sad to throw it away just because it can't evolve as we
> all would like.
> So what do we need to keep it alive?
> 1) We must be able to update the project site and to point all
> links to github. This is needed because many people still use old
> sourceforge tracker to report bugs or enhancements, and github made
> contributions and communication much easier for everyone.
> 2) We must be able to shut down the old sourceforge bug tracker
> and forums and point all links to github.
> 3) We must be able to grant access rights to the github project
> for those who can and will contribute.
> 4) We must be able to publish the new releases to the well known
> download sites or at least point the project webpage to the github
> releases page
> 5) We should configure automated build and test (for example via
> TravisCI as suggested via
> https://github.com/findbugsproject/findbugs/pull/48). Without this
> it is hard to review pull requests, because manual build and test
> requires lot of time.
> 6) We need more people contributing, testing and reviewing patches.
> We have currently 15 open pull requests, and it would be nice if
> they were reviewed and tested.
> What can we do, and which alternatives do we have:
> 1) As one can see, we can't do points 1-5 without Bill. If someone
> somehow manages to contact Bill (twiter/mail/phone/whatever) -
> please do that and get a clear statement from him what he as a
> project leader plans to do to solve the points above. As far as I
> can understand it (looking on Bill public activities), he has no
> will to spend any time on project problems because they don't
> really hurt him. A possible solution here would be to find some
> person to whom Bill have give the admin rights, so that we can
> solve points 1-5 without requesting time from Bill. Unfortunately,
> from my personal experience so far (after many years on the
> project) I believe that Bill still doesn't trust me (because I'm
> from Russia and Russia is evil), so it is very unlikely that he
> will give me admin rights. This is sad, but this is something I
> can't influence in any way. At least I'm happy to know that
> Eclipse projects I'm contributing to *do* trust me (JGit, EGit,
> Platform UI).
> 2) If someone wants to fork FindBugs, this could be a way to go,
> but this should be the last resort from my point of view. A fork is
> the worst thing we can do, but probably better as the dead project
> anyway. My personal advice would be - don't do it, but start your
> own project, without legacy code, or join Tagir on his HuntBugs
> project: https://github.com/amaembo/huntbugs, or join any other
> project in the universe suitable to analyze Java code.
> 3) Without active committers and without changes in the code base
> FindBugs will become more and more irrelevant. FindBugs will not
> support lambda's, type annotations and any new Java 8+ language
> features without major changes in the project state. No serious
> code contribution is possible with the current setup, because I'm
> alone and definitely can't spend so much time for the project. I
> will keep the FindBugs and Eclipse plugin running until there will
> be a better (open source) alternative with Ant and Eclipse support.
> I will be happy to name you a comparable alternative today, but I
> don't see any yet. I hope HuntBugs could be such alternative, but
> it is not yet there.
> That's basically all what I wanted to say for a long time about
> the FindBugs project state, and sorry for the long mail.
> _______________________________________________ Findbugs-discuss
> mailing list Findbugs-discuss at cs.umd.edu
a blog about software development
high-quality Java/JVM content
Free and Open Source Software for the City of Dortmund
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Findbugs-discuss