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.
^ 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
Totally agree. Even worst, the community has already forked and is getting aligned behind https://github.com/spotbugs/spotbugs, his reappearance puts FindBugs in a very dangerous place. It either stays forked, with split efforts and APIs diverging forward, or it's shutdown to trust Bill again and hope for the best.
I for one have lost all trust on his ability to lead the project after such long absence, and the fact that he only reappeared after this hit HN, and only to respond here, to me is an indication he cares more about what people may be thinking / saying of him, than the well being of FindBugs.
I fear, the only way for FindBugs to stay alive, is for Bill to do what he probably should have done a long time ago: step down.
This is also the problem for other projects, the leaders' unwilling to giveup their position even they are inactive for a very long time and just hoping someone could help rescuing the dead horse.
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.
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.
Pretty much that. And to elaborate, there is no shame at all asking for help. I can think of a few ways in which to do this:
- If you are the sole maintainer of a project, putting up a note in the README asking for a co-maintainer or someone to take over the project entirely.
- Responding to emails with, "I'm swamped/I don't think I can do this right now, can you help/would you be willing take on this role?" Totally acceptable. There are lots of eager developers out there who would be willing to contribute to an open source project if they could.
- Posting on HN asking if anyone is willing to help out. :-)
I get that sometimes stuff happens in real life--illness, working long hours, taking care of children or family members--these are all perfectly valid reasons for not being able to put in the time needed to work on an open source project. However, the developer community cannot offer its help if said help is not asked for.
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."
I don't know why you are being downvoted, but I agree with you. The level of entitlement expressed on this forum is off the charts. This behavior is reflected in this case or in case of RethinkDB or any other startup which is closing down, where the frame of mind or needs of the people who build/maintain are secondary to those of customer/users. Its quite a paradox.
> The level of entitlement expressed on this forum is off the charts.
This is ridiculous. Expecting the maintainer who hasn't contributed for over a year (hasn't given any life signs or shown any interest) to give admin rights to someone who genuinely cares about the project isn't entitlement. It's the absolute minimum he could do to keep the project alive at the expense of other peoples time and effort.
Not really. People die unexpectedly. Things come up. Adopting a project with a bus factor of one and expecting things to just work out, and blaming that person instead of yourself when they don't... I think that's pretty close to "entitlement", with a dash of wishful thinking.
Look, open-source projects may be "free" in the sense that you don't pay money for them, but they still cost time. Time to learn, time to integrate into your project, time to debug if things go wrong. Not to mention time to switch to another library if the one you picked doesn't work out for some reason.
As such, there exists a kind of implied social contract between the project owner and users. The owner wants people to use the library[1] and improve it, and the users in turn want semi-frequent updates/fixes and to be informed about the status of the project. Projects that are regularly updated receive more users and contributors, who in turn help provide bug reports, improvement ideas and PRs.
Calling users "entitled" for asking the owners to adhere to the aforementioned social contract, which defines open-source and holds it together like glue, betrays a fundamental lack of understanding of what this ecosystem is and how it manages to be a legitimate alternative to commercial software.
[1]If the owner has other reasons for putting up the project on Github/Gitlab etc (e.g. it's their hobby project, or they want to showcase their code to potential employers), and has no intention to support it, then they should include a note in the readme that the code is not intended for production use. Problem solved.
> As such, there exists a kind of implied social contract between the project owner and users.
No, there doesn't. The "reality" is this: you are using the code I have given out, and that's all you get from me.
I also very much enjoy how you talk about your own free time, and how it's not really "free" to evaluate this stuff, and thus there's a burden etc etc -- and then conveniently turn around immediately and say "but maintainers are required to give me their time, that's part of the social contract". What kind of bullshit is this? It's always the same shit -- time and money for me (I get to reap the rewards, shitpost on your bugtracker, and complain on my blog when you make me mad), none for thee (you're required to help me).
If you're so worried about your own time and your own cost savings -- go buy proprietary code. Or pay the maintainer. Then you can actually have a real contract without handwaving and appealing to non-existent "social contracts".
If you want to whine about taking on risk, maybe you should also bear the burdens of that, as well as the benefits. I'm sorry that's so unfair, but maybe it could teach you something.
> If the owner has other reasons for putting up the project on Github/Gitlab etc (e.g. it's their hobby project, or they want to showcase their code to potential employers), and has no intention to support it, then they should include a note in the readme that the code is not intended for production use. Problem solved.
So your answer is that we should always assume this "social contract" exists with every piece of code, and thus maintainers are obligated to slave away for us unless specified otherwise?
This entire post reeks of nonsense entitlement-justification. I do not owe you my free time because I posted a library on GitHub, though I may choose to give you my time. I am also free to rescind that offer at any time, and guess what -- I do not need your approval to do so (because, really, you are not that important). End of story.
>>No, there doesn't. The "reality" is this: you are using the code I have given out, and that's all you get from me.
Fine, then say so on the readme file! It's not lack of updates people are worried about. It's the uncertainty that comes with not knowing whether the owner intends to continue developing it or if they have abandoned it. If you pay some attention, you'll see that's what this entire conversation is about: the owner of a popular project being the single point of failure and then going missing.
>>I do not owe you my free time because I posted a library on GitHub, though I may choose to give you my time. I am also free to rescind that offer at any time, and guess what -- I do not need your approval to do so (because, really, you are not that important). End of story.
Again, no one is asking for your free time. If you don't want to update the project or push fixes, fine, whatever. The only thing people are asking you to do is to transfer ownership of the project - or at least admin/maintainer rights - to someone else in a responsible manner if you decide to abandon it. You may call this "entitlement." I call it "being an adult."
And frankly, get over yourself. You aren't that important either. Just because you posted a piece of shitty code on Github doesn't give you the right to act like an asshole when people come to rely on that code. Try not to let it get to your head too much, mmkay?
Understanding that a project with a single maintainer may become unmaintained unexpectedly should be common sense.
> Again, no one is asking for your free time.
You literally are. Including the time and energy needed to decide whether or not to continue maintaining the project, and to hand it off in an appropriate way.
> Just because you posted a piece of shitty code on Github doesn't give you the right to act like an asshole when people come to rely on that code.
Is this normally the tone you take when asking people who helped you to keep helping you?
Just because you randomly downloaded some code from Github and chose to rely on it doesn't mean the author owes you a damn thing. Don't like it? Fork it. That actually is how open source works.
Open source software runs the gamut from unmaintained to supported by a foundation with multiple corporate members, a board, and plans in place to ensure continuity under various adverse circumstances. How much stability do you need?
It isn't the responsibility of the project owner to tell you that their project doesn't meet your needs. It is your responsibility to check how the project is run and choose whether or not to take on that risk.
People actually doing the work of evaluating the risks they are taking on is how open source actually does become a legitimate (sometimes safer) alternative to commercial software.
People not doing the work, taking on risk without doing their homework, and then whining when it bites them in the ass is, well, "the story of left-pad".
I agree. It's also odd that this clarification of the project status has been posted here now and there has been no reply to that thread in (what I think is) the official mailing list, which has been going on for around a week, where people have been trying to get in touch with him.
I have been involved in open source and non-commercial, volunteer driven projects for at least a decade. It's true that it's not right to demand volunteers who spend their time on the projects to answer questions. However, in this case, having read the mailing list thread and even the parent post to which you replied, I don't believe anyone is _demanding_ anything from the project owner.
People who are passionate about a project, as a user or contributor, do tend to ask what the status/roadmap of a project is. At least in open source projects I contribute to, that's not considered as demanding something from the project leaders, just because no one has paid for the project.
IMO, there are times where it's valid to state that no one has paid for the project so aren't entitled to anything, but I don't think this case is a valid one. I've seen this statement being used many times with open source projects and such project usually tend to lose sight that users are a central part of open source projects.
I agree with all you say. And I also understand being angry about a project for not considering me as a user enough.
However, "There is absolutely no reason to not be answering emails" gave me the impression that at least one person is demanding replies to emails. I still feel it's okay to tell the quoted person that if he doesn't pay someone he can't demand from that person to answer emails.
Last but not least, if someone hasn't answered emails for some time, who seemingly had enough trust before to be important in a software project, then it may be wise, even for people with legit demands, to see whether or not that person had good reasons for his absense or not.
I'm not even talking about the software. I'm talking about the people that were the active maintainers who made a few attempts to connect with him over the course of a year, being let down. And the response after that time of "ok, I'm back now" after a Hacker News post hits the front page, without apology or explanation to them.
That's great, but it feels you have been a single point of failure on a widely used project. As well as rebooting the project do you have any plans to expand the admin role so it's harder for the project to find itself in this situation in the future?
* 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
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.
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.
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.
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.
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), 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.
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.
The distinction I was trying to make was one between where in the toolchain it lives: error-prone is part of compilation, whereas Findbugs is after-the-fact.
Error-prone is a compiler plugin _mechanism_ - once you have an error-prone compiler, the checks are arguments to the compiler just like APT annotation processors are.
It's built on a standard API - the JavaCompiler mechanism built into the Java SDK - but yes, the code does have further dependencies on com.sun packages. This is a little confusing because why expose the compiler for invocation and extension when extensions have to rely on unsupported code?
So, yes, there are ways where the distinction is important, but they're orthogonal to the point I was trying to make.
Error-prone is somewhat tied to a specific version of the Java compiler -- so you need Javac 8, but you can set --source to an older version of the language. If the newer Javac does not emit bytecode that works with your runtime, you can run two compiles (one error-prone for the errors, one production compile with whatever compiler you need).
Haven't we learnt several times in the past that this is a bad idea? Eg. with Android or GAE/J. This is going to require a lot of effort for every upcoming Java release delaying support for a long time, again see Android or GAE/J. It also makes integration with Eclipse difficult at best.
It depends on what you mean by "bad idea". You've got three choices, basically: analyse source, analyse the AST, or analyse bytecode. There are advantages and disadvantages of each approach, but for what Google's trying to do - allow people to write their own checks - there are clear advantages to analysing the AST.
I've written checks in both error-prone and Findbugs and error-prone is simply more natural. Part of that is the Findbugs API, for want of a better word, is godawful, but the AST is simply the best representation of the program for analysis.
If you're going to analyse the AST, you then have a further two choices: build your own AST, or hook into the compiler. Building it yourself is dangerous here: firstly, it's repeating a lot of work that's already been done, but more importantly you want to be absolutely sure that what you're analysing is what you're actually building. Either way you have to do updates when the language changes, as any static analysis tool needs to.
Are there costs to this decision? Yep. Is it going to be the right tool for every job? Nope. But that doesn't mean that these decisions don't have reasoning behind them, and compelling reasons to go this way.
I am not questioning the AST approach. I'm questioning the approach of hooking into JDK internals and using JDK internals as an interface for custom check implementations.
Google has done similar things several times in the past (GWT, GAE/J, Android) and every time updates to the latest Java required a lot of effort, were therefore late and eventually abandoned.
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.
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?
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" :).
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.
Scan finds lots of bugs for open source projects at no cost. Sure it is marketing, but unlike most marketing it also has real value.
Not sure I can comment on the results on your own code, but I will say that volume of results is not always correlated with value in static analysis. There are plenty of noisy rules that basically have negative utility if you factor in the time it takes to review each issue. It's a complex balancing act between finding more issues, having fewer false positives, analysis time, understandability of results, and other factors.
True for my organisation as well. Most of the code is C/C++. So it would make business reason to support the community of the open source product that does not directly compete with Coverity while using it to complement the business offer.
Talk them out of renewing and be sure to let the salesperson know that you don't appreciate their ethics. With all the alternatives it's not like you'll be left high and dry.
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.
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.
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.
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.
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.
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.
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.
Did they make any changes to those libraries? I'm also using tons of open source from github but I almost never make any changes. I do report bugs and sometimes I add workarounds to the bug report, mostly for code I'm comfortable to inspect and modify. That's almost only Ruby, JS, Python, nothing that needs more than an editor and a browser reload: I have no time for that and I'll just look for another library.
There is no incentive to contribute to a project in such poor shape.
SonarQube abandoned FindBugs mainly because it was low on activity:
"FindBugs project activity: The activity on the project is quite low and thus the value coming out of it does not come fast enough to satisfy our users."
Does the license not allow forking it with group of people more interested in accepting contributions? It has a bunch of users. If my theory is wrong, it should've forked with a lot of updates by now.
Yes, it's allowed ('though the name is trademarked). However, forking is usually harmful (effort spread thin, divergent APIs, plugins, integration with other tools such as Maven, Gradle, ...).
On that very email chain, once the sitution was stated and as Bill kept on ignoring everyone as he did over the last year and a half, the community hard forked FindBugs and started aligning behind https://github.com/spotbugs/spotbugs
Bill's reappearance is now puzzling. To abandon the fork to go back to FindBugs would require major leadership changes, as confidence on Bill has been shattered. Keeping the fork leaves the project on the same point people tried to avoid in the first place.
In this case, sounds like the source lost interest, a fork didnt have enough to accomplish anything, and now a good project is toast. Despite it being OSS with significant adoption.
Sounds like quite a few precautionary tales in this one.
The status quo if you are a defunct project without any means to properly accept contributions or even just mention a new release on the homepage maybe. There are many example where open source as a model works, but you can't expect that it will magically solve all problems. Especially if you as a project are not even able to get the basics right. How is that supposed to foster contributions to the project?
Most successful projects in FOSS with many downloads get virtually no contributions or financial support back. Even the largest ones have an enormous user to contributor ratio with almost all benefits going to the users. Therefore, it's the status quo for open-source in general. Those getting tons of contributions and development without a company behind them are extremely rare.
I had a great article on this before my crashed HD deleted newer bookmarks. It was a woman that surveyed many popular projects to ask about their status. Most complained they were barely getting by, the developer(s) stretched thin, tons of requests without accompanying payment/support, and mostly no contributors. I'd like a link to that article if any readers know which one I'm talking about.
She never ended up finding a solution to the problem and instead ended up joining GitHub as a opensource developer advocate (or something similar to that).
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.
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.
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).
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.
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
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?
> 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).
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).
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?
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.
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.
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.
You're getting some flack for this, but I agree with you based on what we've seen with Error Prone. The people who design programming languages are human, and they make mistakes. Unfortunately, if your language becomes successful, it becomes nearly impossible to fix these mistakes while retaining backwards compatibility.
Many of our checks are essentially working around problems with the language or API design. For example, our ForOverride checker (http://errorprone.info/bugpattern/ForOverride) addresses the fact that existing Java visibility modifiers are not expressive enough for some things the Guava team wanted to do. Our HashtableContains checker (http://errorprone.info/bugpattern/HashtableContains) addresses an issue with a poorly-named method in the old Hashtable API, which really should be deprecated but is infeasible given the old code that uses it.
I think if you could say that about any language it'd be Kotlin. It seems to take all of the best practices guidelines from Java and just bake them in to the language.
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