Even among veteran stamp collectors most have probably never seen a Form 3, but they need one every time they buy a new product from a dealer. The Form 3 is what licensed dealers use to tell the ATF that ownership of a registered NFA item is transferring from one licensed party to another, and in theory it should simply be a rubber stamp process. Both parties are already licensed, all that needs to happen is that the ATF updates its books and sends the green light to the dealer in question. This simple process should be instantaneous with the technology available today, but instead it still takes nearly a month for paper copies to work their way through the system and back. The ATF was planning on digitizing the process to make things easier but apparently that has once again been pushed back. And also delayed the return of the digital eForm 4.

The following email was sent to a select group of licensees who were involved in a small scale test of the system, and based on the report things don’t look good.

We had hoped to be able to present the first iteration of FEAM at the 2016 SHOT Show.  Last week we performed an assessment of what was contracted to be developed for FEAM and what the contractor planned to deliver.  At the end of the assessment, all parties involved felt that the product outlined in the current contract did not fully provide all the functionality that we expected, or that the industry requested.  For these reasons we decided that rather than to continue on the current course, we would take the steps listed below to ensure that FEAM is a worthwhile investment for both the industry and ATF:


  1. Curtail the current development effort.
  2. Determine what is needed to sustain the existing eForms system, until the full requirements for FEAM can be determined and developed.
  3. Make the necessary changes to eForms to stabilize the infrastructure with the ever-increasing user population.
  4. Determine if we can re-introduce the Form 3 to the current eForms, through load testing and other system validations.
  5. Perform an assessment of the ATF and industry requirements for FEAM.
  6. Secure required funding for a new FEAM initiative, based on the revised requirements.
  7. Restart the FEAM initiative, to include industry participation during the requirements gathering and testing processes.

We look at this as only a minor delay.  It is our intention to use this delay to acquire the tools and resources necessary to develop a product that will provide more functionality and a stable workflow process and infrastructure.

Given how unstable and buggy the original ATF eForms website was I’m perfectly happy to cut them some slack and allow them to get the bugs out of the system before they go into full production. Then again, this is something that should have been complete years ago.

[h/t B.M.]

Recommended For You

33 Responses to ATF eForms Delays Form 3s and 4s… Again

  1. But why can’t I fund the agents of my destruction! I demand to give the draconian government my money so I can have overpriced short barrels(less material equals mo money) and baffled(baffling) tubes to make slightly less noise.

  2. Where does the NFA spell out that you need extra special permission to build a item controlled by the law? I get the taxing authority part. But I have never seen read the part that says that you need approval of CLEO. It seems to me that in 1938 they knew the law would be unconstitutional if they just outright banned ownership. So using the power to tax they limited the people who could afford the. weapons. Ok so I will out a form,I pay the tax, they give me a receipt, and I build the weapon. Should take all of 20 minutes max. I don’t see where the extra special background checks and permission from CLEO was ever authorized by Congress. I’m not saying its not there, just that in reading the law I don’t see it.

  3. Anyone remotely familiar with software development will instantly recognize an effort that was a total failure from the very beginning. No requirements before the contract was let for development? Really? They should be fired.

    • As a person in the industry I actually am 90% willing to attribute this to stupidity not maliciousness. If it was bid out as a contract there was likely a lack of domain knowledge, it went to a low bidder or someone connected to a person in the bidding process, they had vague requirements to begin with that had scope creep later on, they may have been expected to integrate existing data and lastly either the people implementing or the project manager wasn’t the sharpest knife in the drawer. There’s also an adage in the industry, “hardware gets broken with age, software gets fixed.”

      The existing site could have issues with infrastructure (some of the gov stuff is pretty sad) and/or they could have code issues. Quite frankly I would lean towards the latter, and that they are throwing infra at it to mask the issue best they can.

      As stated, this is why they should be obligated to let a gun be sold after 3 days. They can’t get their act together well enough to actually manage a project like this. I do infrastructure for a living, if you’re listening ATF hit me up and we’ll try to get this sorted out.

      • I don’t get why upgrading is such a big deal. I worked for health plans and got to see first hand what several mergers looked like. The programmers all made a big deal of impossible it was to bring everything into one system. At the end of the day, after some testing, the database was dumped into a flat file and pulled into the new database. It was stressful, yes, but not the daunting impossibility that many made it out to be. Ooops we screwed up the file was flawed, both databases were trashed. ok roll back to yesterdays backup and we try again next week. (Yes I am aware that it can many hours to do this but it is usually first attempted on a test system.)

        So at the end of the day when I hear that it takes years to develop a system like this I call BS. What are the real questions?
        1. What database will we be using? (Most likely some flavor or SQL)
        2. What data needs to be stored in the system?
        3. Who will have access to data? (users, permissions, etc.)
        4. Security
        5. What will the host OS be? (hopefully *nix but even if not doesn’t really matter)
        6. Backup solutions?
        7. Front end system (GUI) (This will most likely take the longest to create since users need something intuitive and programmers usually fail hard here. Not to mention end users tend to expect something completely different a year later then they asked for. )

        Bottom line the amount of time it takes for the Gov to implement new systems is atrocious. The result is also equally atrocious. What really pisses me off, is the cost. These programs are implemented insecure, unstable, slow, convoluted and barely work. Meanwhile a company like Amazon creates an entire company for less then the cost of a Gov website.

        • http://www.stilldrinking.org/programming-sucks

          This is a good read on the topic, it will give some insight as to why this is an issue. Government makes it worse. It’s really important to remember the government typically doesn’t fine its self, if your’e talking health care stuff they can be fined if they lose data and unavailability is really nasty when lives depend on it. There’s a heck of a lot more motivation to have something that works vs having something at the lowest price point with low accountability by the people in charge.

          Porting data in isn’t that hard at times, even across database platforms it’s doable. Cleanliness can be an issue though. I agree that they should be able to do it in this case if their original stuff isn’t garbage too. There’s definitely the possibility of it having some “crustiness” to the data that has to be massaged out though.

          If you’re developing on prod you’re doing it really, really wrong. If you’re using backups to make copies for your dev, you’re doing it really wrong. At the very least SAN storage with clones/snaps and VMs should be used as you can create duplicates of the environment very easily and grow it as needed. After you get the new system up, you do a maintenance window, cut over and re-sync the records one last time.

          These days agile techniques and something in a PaaS format like Cloud Foundry should be used. For some of the “bigger” stuff (DB Servers for instance) something like Puppet should be used to automate the implementation at the host level. This makes it where the environment can be grown over time without breaking it horribly. You just add a new host, configure it with puppet or install Cloud Foundry, spin up new instances and add them to your balancer.

          Another thing to remember here is that even if they hire the best coders in the world if they suck in the area of domain knowledge it can and likely will hold the project up. This is likely where a lot of these projects get screwed up, and combined with scope creep it’s even worse. Doing things like getting change approvals, tapping into authentication systems and getting security clearances etc. can hold them up as well.

          Amazon is definitely not a fair comparison. The government is not in the IT industry, Amazon is. Amazon has to survive by making a profit, the government doesn’t. This business model has hit a lot of areas of industry (IT As a Service) but that’s a heck of a change to get the government on board with and it will likely take someone combining a lot of silos. Good luck with that. They also have their issues, their flaws etc. The reason why people are successful on Amazon Infrastructure (e.g. Netflix) is that they design the workloads for Amazon to be unreliable and in turn the system as a whole is reliable.

  4. No identifiable contract, standards supposedly not met, scrapping after contractor failure…yeah, pretty much think they needed to say something about a non-existant program to bring it back online before SHOT. More BS!

    • Same list of contractors from which the vendor was chosen to implement O-care.

      Gov’t does not have adequate resources (people who understand IT and the operational world, and can translate between) to create or evaluate Statement Of Work. It is pretty much ad hoc. Contractors are not profited by helping the gov’t bridge the gap (contracts for “best effort” are preferred, followed by “time and materials” contracts.

      Gov’t cannot understand a dynamic world because all of government is predicted on stasis, which means rigid controls for rigid purposes (if you can’t fit your need/request into the regimented system, you shouldn’t be doing business with/part of the gov’t.

      On top of all that, you can then add bureaucratic games designed to increase power, spread the agency footprint/territory, frustrate those being regulated…hopefully enough that they will comply without complaint, or just go away.

      Never forget, gov’t budgeteers believe the economy is static. Thus, when asked to project the tax revenues if all wealth above $250k was confiscated from tax payers, those projections actually projected increased revenues from year 2-10.

      Your government at work, working for you.

  5. The law only require fingerprinting. The rest is ATF creativity. As for the eForm 3, it was digitized, then they undigitized it due to too many people submitting batch files (multiple applications being submitted all at once). I guess they still lhaven’t figured out how to fix that.

    • For new age technology that’s EXACTLY how it should be done. There should also be an API so that dealers and manufacturers can interface their application directly with the system. Manual entry should actually be pretty darn rare quite frankly.

      • I would argue that there should ONLY be an API; why make a public facing front end for something like this when there is still a paper method? You can go ahead an phase out the paper method once there are sufficient consumers of the API that no one has an excuse not to just use one. Given the absolute simplicity of what this is doing (collecting form info, allowing a human to analyze the form, then giving up the results) the API would not have to be very complex; I can almost guarantee someone would make an open source software to collect the form info and submit it via the API, then retrieve the result (preferably by giving a reply url along with the submission) and stow it away for the end user to see later within (at most) months of a sane API being available.

        • There should be a basic, usable web interface provided by the government for this system. The added cost and resources to do such are minimal. It also provides a migration pathway and time for inventory tracking software companies to develop integration with their systems. Even with paper forms, someone still has to enter the data somewhere, right? Why make that work load any more than it has to be, and why go to the expense?

  6. The first time I registered and used the eForms site, I was somewhat bewildered at how amateurish the site is. As if someone high up in the ATF recruited their son, out-if-work brother-in-law, or hunting cabin neighbor “who’s pretty good with computers” to design and code it. One wonders how many millions were wasted on it.

    • As if someone high up in the ATF recruited their son, out-if-work brother-in-law, or hunting cabin neighbor

      High up or just high?

    • lol. Try using EFTPS. Same thing. I have to call in for instructions to figure out how to change drafting banks. (They have instructions online but of course the website has been changes 1/2 a dozen times since those instructions were written.) Every gov website I’ve used looks like something I made on AOL in the early 90’s.

  7. I work in software that creates fill-able documents that are completed online then uploaded to populate tables in a database. Some of the online docs my company has created are even federal documents that used to exist solely in paper form. Creating a functioning document only takes a few days for one person. After that, it’s just bandwidth and storage – two items that are easily purchased by any competent IT manager.

    This is 100% the ATF dragging their feet.

    • Like their private industry counterparts, government employees don’t know what they are doing. That is, they don’t know how their functions/agencies/processes work, anymore than we know precisely which body mechanisms are activated just to breathe. That being said, most government types are more concerned with process than outcomes. When faced with the question, “what if all your manual steps were automated according to your business/agency rules and processes, and once you input the raw data, answers and recommended action are produced?” The employees almost immediately begin to clamor for proof that all the outcomes are “right”. Asked what that means, they generally respons, “How do we know all the rules are included in the software, and how can we identify who made which entry at which moment?”. Responding that the software contains all their rules and procedures, the employees are skeptical that they can actually identify all the “hoops” they jump through to accomplish their tasks. Kinda hard to program in that environment.

Leave a Reply

Your email address will not be published. Required fields are marked *