Now How Do I Use This Old Scanner Again? NAPS2!

I have an old beast for a printer/scanner. It is nine years old in human years, which is like one hundred in technology years, but it gets the job done.

One problem I’ve run into repeatedly over the years is that of scanning software. At some point in the distant past the software that came with the scanner disappeared. Yes, one can still download the drivers off of the manufacturers site – but I’m talking about the software that makes the scanning process easier and more robust. Usually this software is from a third party company and thus the manufacturer’s site doesn’t include it as a download. So what is one to do?

Not Another PDF Scanner 2 ScreenshotYou’d think there must be tons of free software options out there for such a simple and fundamental application – you’d be surprised (at least I was). Over the years I’ve used numerous different applications to scan – some commercial trials (FileCenter being my preferred one, but way too expensive for an occasional scan) and lots of crappy free programs.

Well, no more. There is now an excellent, free, and open source option available called NAPS2 (Not Another PDF Scanner 2).

What makes it so great? I’m glad you asked!

  • File Format Support – It can create PDF, TIFF, JPEG, PNG, and other file types (I find the PDF support especially useful for multi-page documents).
  • Automatic Document Feeder / Duplex Support – ADF means that it can handle multiple pages without requiring user intervention and duplex means it can handle double-sided documents also without user intervention.
  • Simple Scan Management – Rotate pages, straighten images, crop, etc.
  • Optical Character Recognition (OCR) – Supports identifying the text in scanned documents.
  • Powerful – Need to automate your scanning using a command-line interface? How about distribute it via Group Policy? No problem.

Why the Healthcare.gov fiasco SHOULD teach us to Open Source Government Application Development.

We Spent How Much?!

According to The Daily Beast the United States Government has spent $118 million to build Healthcare.gov and another $56 million in fixing it…and based on the fact that the site isn’t expected to be fully patched for some time yet I wouldn’t be surprised if the total cost in “fixing” exceeds that of building the system in the first place.

Image courtesy of OpenClipart.org and Iwan Gabovitch
Image courtesy of OpenClipart.org and Iwan Gabovitch

I’m not going to take a position on the Affordable Care Act (ACA) – I try to avoid speaking publicly on controversial issues…but I would like to suggest a lesson we can learn from the ACA that I don’t think will be (very) controversial across party lines – that the Government should utilize open source in the development of applications as a standard rule.

Now, I’m not particularly interested in arguing that every government project should be open source – I’ll be happy if 95-99% of them are. I understand that some people rightly or wrongly believe that using open source in sensitive areas could cause security risks. I’ll let Kevin Clough and perhaps Richard Stallman[1] argue that point.[2] But for the vast majority of projects (Healthcare.gov for example) I can see no reason why the development should not be open source and believe there would be significant advantages to such a course of action.

Lets take a look at the specific ways in which open source development could have reduced or eliminated the issues involved in the Healthcare.gov launch:

Transparency

The government (not just one department, but its entirety – e.g. the white house and congress) and the public could much more readily have seen that issues were arising, deadlines were slipping, etc.  and made necessary adjustments.

It is a constant problem within organizations that individuals at higher levels make decisions without the proper knowledge base upon which to make such decisions. This can result in unrealistic timelines and even if the timelines are realistic, if unexpected issues arise and there is slippage, there is a temptation to “gloss over” the setbacks and “hope” that the timeline can still be met.

This oftentimes results in extreme pressure on those actually working on the application as they are pressured to produce more, quicker – which, especially in the case of programming – is unwise. The more you pressure programmers the more likely they are to make mistakes, to take shortcuts and the more hours you demand of them the less productive they will become and, again, the number of bugs will grow exponentially.

Bug Fixes

Open Source software is oftentimes very stable and secure because of the number of eyes looking over the code. Further, individuals who are amateurs can make small contributions that allow the programmers to development on system architecture and bigger issues instead of stomping out bugs and making aesthetic improvements.

It would make sense for the Government to take a similar approach to Microsoft, Google, and Yahoo! on this front – each offers cash rewards for the discovery of issues. This is a relatively inexpensive way to get folks to pour in their energies – and individuals receive (for them) a significant compensation (hundreds to thousands of dollars – depending on the issue discovered).

Load Testing

The failure to properly load test the Healthcare.gov site is shocking. An open source project still needs robust methods of load testing performed by the core team – but it also benefits from other individuals and organizations implementing the application and discovering bottlenecks.

An open source, distributed team, also could have easily simulated the significant load that the site experienced upon launch – exposing the load issues early enough for remediation.

Code Reuse

When a project is open source the code can be reused by others for all sorts of purposes. The code to this project would certainly have applications in other government projects as well as the private sector. Reuse of code can significantly streamline development timeframes and even if someone in an entirely uses a portion of code for an entirely different project in a different industry – they will oftentimes contribute their version of the function (with enhancements/bug fixes) back to the original project (resulting in better, more flexible, secure, and robust code).

Cost

I really am just spitballing here – but I have a hard time believing that the development of an open source system to perform the Healthcare.gov functions would have cost anywhere near the costs expended thus far upon this closed source system. I’d guess that $10 million could have completed the project in a more robust and timely manner via open source.

Lesson Learned?

Please, let us take a lesson from this fiasco. We want more affordable healthcare – we can start by not wasting millions developing an application as a closed system which lacks robustness and stability.

I know some areas of the Government are already working with open source (and that is great) – but this needs to be a greater emphasis. Perhaps (I don’t know) there should even be some legislation that makes the (required) standard for new applications be open source and any applications which are desired as closed source systems should require review by a panel to determine if there is actual, substantial reasons for developing in a closed source system.

[Apparently I’m not the only one to think OSS could have made a huge difference. See this article by Christina Farr over at VentureBeat. Not directly related, but still interesting is Dylan Tweney’s article “Healthcare.gov costs show that feds have literally no idea how to build a big web site” also on VentureBeat. Another article comes from NBC News staff writer Gil Aegerter and can be found here.]

[11/4: Good article from Matt Asay entitled, “Sorry, Open Source Isn’t the Panacea for Healthcare.gov” on ReadWrite.]

  1. [1]Though Stallman would argue for free software rather than open source, but I leave that semantics argument, however important it may be, aside for the time being to focus on an area in which a relatively minor change in procedure (moving to open source development) could make a significant change in cost and efficiency.
  2. [2]There are some excellent arguments on how and why open source technology can be more secure than closed source technology. Specifically, the additional security in closed source systems usually isn’t b/c the systems are actually more secure but a function of “security by obscurity” – in other words, security holes exist, no one knows about them (including those who wrote the software). But I digress…

Tech News Summary for May 8th, 2013.