[FB-Discuss] Project status
Tagir F. Valeev
amaembo at gmail.com
Wed Nov 2 09:34:48 EDT 2016
Just a short note about HuntBugs. It has its problems too: it depends
on Procyon Compiler Tools which while incredibly better engine
compared to BCEL, also suffers from lack of maintenance, and has some
unpleasant issues. Also currently HuntBugs development is on hiatus as
I devoted all my time to IntelliJ IDEA (which, to my opinion,
currently is the best static analysis tool for Java). Still if
somebody like to join HuntBugs development, you're welcome. At least I
managed to cover about 40% of FindBugs functionality (not to mention a
handful of new detectors) in three months (mostly in spare time) which
says something about the easiness of development from the scratch. It
already includes non-trivial things like control flow graph and
data-flow analyses (null analysis was under development when I stopped
working on it). Writing simple detectors is just piece of cake.
With best regards,
AL> Hi all,
AL> TL;DR: I'm really sorry to say, but FindBugs project in its current form
AL> is dead.
AL> Longer explanation follows.
AL> Current project setup is:
AL> 1) On the plus side, we have two committers with push rights to the
AL> github repo, however one from this two (Tagir) is not active anymore for
AL> the project and second one (me) has no free time to work on the project.
AL> That's however all about the good things...
AL> 2) Only the project leader Bill Pugh has admin rights for the project
AL> web page and the github project group and page. We cannot deploy any
AL> website update, we can't add new project members, we can't manage code
AL> access rights, we can't publish releases to the well known update sites
AL> without his help. Without him, we have no admin rights to anything, we
AL> can only push to the repository.
AL> 3) It looks like Bill Pugh is not interested in the FindBugs project
AL> anymore, and we can't reach them. I say "it looks like" because we
AL> requested his help for the project many times (via direct mails,
AL> postings to the list and to the github issues) but haven't received any
AL> sign of life from him since a year. We know that he is active elsewhere
AL> (https://twitter.com/wpugh). A week ago I've sent another mail to Bill
AL> (and CC to the findbugs-core at lists.sourceforge.net mailing list) asking
AL> him about the current project state - with no answer so far. You can
AL> read my mail in the attachment. IMHO no answer to this mail was the
AL> answer enough. Either Bill has completely lost access to his old mail
AL> account (which is possible too) or he is ignoring me or the project
AL> (which is more likely).
AL> If someone has a possibility to contact him in some way
AL> (twitter/mail/phone/whatever) and point him to the discussion on this
AL> list - please do so!
AL> Without Bill Pugh FindBugs project is headless and effectively *finally*
AL> dead. It is not the *only* reason for the project to be dead, but a
AL> bigger one, and the last one.
AL> The other major reasons for the FindBugs current bad state:
AL> 1) The code is very complex, has "organically grown" over a decade, is
AL> not documented and has poor public interfaces. Most of the code consists
AL> of the very low level bytecode related stuff, tightly coupled with the
AL> ancient BCEL library, which doesn't scale and is not multi-thread safe.
AL> No one enjoys maintaining this code, at least not me. I see no future
AL> for FindBugs with the BCEL approach, and see no way to get rid of it
AL> without investing lot of effort, and without breaking every detector and
AL> possibly many 3rd party tools. This is the biggest issue we have with
AL> FindBugs today, and most likely the root cause for all the evil. This
AL> code can't be fixed, it must be rewritten.
AL> 2) Because the code is as it is, there are not so many people willing to
AL> contribute. We see some pull requests on github, but most of them are
AL> smaller fixes or enhancements (many thanks to you guys, and sorry I have
AL> no time to review and test all of them!). Those who were willing and
AL> able to contribute leaved the project one by one. At last, we had Tagir
AL> contributed lot of things (many thanks!), but since he left us for his
AL> own project (https://github.com/amaembo/huntbugs) we saw no major code
AL> contributions anymore. BTW the fact that he left the project is also a
AL> sign that the project is in a very bad shape - it was easier for him to
AL> write the code from scratch as to continue supporting FindBugs.
AL> Currently I'm the last committer left on the project, and I'm not really
AL> active because lack of the free time. We clearly failed to build a
AL> contributors community.
AL> 3) We have *zero* support from organizations. There are no companies
AL> investing into the project in any way (neither via code patches or
AL> testing, nor via spending developers time for the project), although I
AL> know there are companies using FindBugs in their commercial products,
AL> for example SonarSource and Coverity, and of course there are many
AL> companies and projects just using FindBugs in their build processes.
AL> Add to this the project leader ignoring all communication with the
AL> project and you will agree with me that FindBugs today is a headless
AL> "zombie" project without future.
AL> However, FindBugs is still useful, even in its current state, and it
AL> will be sad to throw it away just because it can't evolve as we all
AL> would like.
AL> So what do we need to keep it alive?
AL> 1) We must be able to update the project site and to point all links to
AL> github. This is needed because many people still use old sourceforge
AL> tracker to report bugs or enhancements, and github made contributions
AL> and communication much easier for everyone.
AL> 2) We must be able to shut down the old sourceforge bug tracker and
AL> forums and point all links to github.
AL> 3) We must be able to grant access rights to the github project for
AL> those who can and will contribute.
AL> 4) We must be able to publish the new releases to the well known
AL> download sites or at least point the project webpage to the github
AL> releases page (https://github.com/findbugsproject/findbugs/releases).
AL> 5) We should configure automated build and test (for example via
AL> TravisCI as suggested via
AL> https://github.com/findbugsproject/findbugs/pull/48). Without this it is
AL> hard to review pull requests, because manual build and test requires lot
AL> of time.
AL> 6) We need more people contributing, testing and reviewing patches. We
AL> have currently 15 open pull requests, and it would be nice if they were
AL> reviewed and tested.
AL> What can we do, and which alternatives do we have:
AL> 1) As one can see, we can't do points 1-5 without Bill. If someone
AL> somehow manages to contact Bill (twiter/mail/phone/whatever) - please do
AL> that and get a clear statement from him what he as a project leader
AL> plans to do to solve the points above. As far as I can understand it
AL> (looking on Bill public activities), he has no will to spend any time on
AL> project problems because they don't really hurt him. A possible solution
AL> here would be to find some person to whom Bill have give the admin
AL> rights, so that we can solve points 1-5 without requesting time from
AL> Bill. Unfortunately, from my personal experience so far (after many
AL> years on the project) I believe that Bill still doesn't trust me
AL> (because I'm from Russia and Russia is evil), so it is very unlikely
AL> that he will give me admin rights. This is sad, but this is something I
AL> can't influence in any way. At least I'm happy to know that Eclipse
AL> projects I'm contributing to *do* trust me (JGit, EGit, Platform UI).
AL> 2) If someone wants to fork FindBugs, this could be a way to go, but
AL> this should be the last resort from my point of view. A fork is the
AL> worst thing we can do, but probably better as the dead project anyway.
AL> My personal advice would be - don't do it, but start your own project,
AL> without legacy code, or join Tagir on his HuntBugs project:
AL> https://github.com/amaembo/huntbugs, or join any other project in the
AL> universe suitable to analyze Java code.
AL> 3) Without active committers and without changes in the code base
AL> FindBugs will become more and more irrelevant. FindBugs will not support
AL> lambda's, type annotations and any new Java 8+ language features without
AL> major changes in the project state. No serious code contribution is
AL> possible with the current setup, because I'm alone and definitely can't
AL> spend so much time for the project. I will keep the FindBugs and Eclipse
AL> plugin running until there will be a better (open source) alternative
AL> with Ant and Eclipse support. I will be happy to name you a comparable
AL> alternative today, but I don't see any yet. I hope HuntBugs could be
AL> such alternative, but it is not yet there.
AL> That's basically all what I wanted to say for a long time about the
AL> FindBugs project state, and sorry for the long mail.
AL> Kind regards,
AL> Andrey Loskutov
AL> Am 01.11.2016 um 21:53 schrieb Juan Martín Sotuyo Dodero:
>> Hi everyone,
>> Over the last week I've been talking with several members of the
>> FindBugs community and so far we all share the same worries. FindBugs is
>> stagnant due to the prolonged absence of Bill Pugh.
>> It's hard to imagine a future for FindBugs where no one can update the
>> SourceForge pages, make a release on SourceForge, enable a CI server
>> such as Travis, add members to the GitHub organization or even publish
>> to Maven Central.
>> Currently only Andrey Loskutov sees to be active. I've seen him trying
>> to get Bill to perform many of these tasks over the past, and retrying
>> recently, but time keeps passing. It's been 9 months since he requested
>> to update the site
>> <https://github.com/findbugsproject/findbugs/issues/80> and 13
>> since people requested to enable Travis
>> I would like to know if anyone has any knowledge of Bill's current
>> status. His github page <https://github.com/billpugh> shows he has been
>> working sporadically over the last year, but always on other projects.
>> I strongly believe the team needs to get reorganized, but I fear without
>> Bill to grant accesses, this is next to impossible. Myself and those
>> I've contacted dread this horrible idea, but fear that the only way
>> forward as things stand is forking FindBugs. This is clearly a last
>> resource, and under no circumstance our first choice; but as months keep
>> passing, it seems ever more appealing.
>> Is there any way the current situation can be reverted? Can we help in
>> any way?
>> Shall there not be, we are most likely to start a new organization and
>> adopt a different name (FindBugs is trademarked), but would probably
>> commit to keeping binary compatibility (public APIs) to minimize
>> transition cost for anyone moving with us. Everyone willing to
>> contribute would be more than welcomed.
>> Once again, we would rather not have to take this course. I hope it can
>> be avoided for the sake of FindBugs.
>> Thanks for your time
>> Findbugs-discuss mailing list
>> Findbugs-discuss at cs.umd.edu
More information about the Findbugs-discuss