Slashdot Mirror


The US Government and Open Standards: a Tale of Personal Woe (thevarguy.com)

An anonymous reader writes: This article details a Linux user's struggles to submit a grant application when the process requires finicky, proprietary software. It also covers familiar ground made timely by the upcoming elections: the U.S. should prefer open source software and open standards over proprietary alternatives. The grant application required a PDF created by Adobe Acrobat — software Adobe no longer supports for Linux. Once the document was created, attempting to submit it while using Ubuntu fails silently. (On Windows 7, it worked immediately.) The reader argues, "By requiring Acrobat the government gives preference to a particular software vendor, assuring that thousands of people who otherwise would not choose to use Adobe software are forced to install it. Worse, endorsing a proprietary, narrowly supported technology for government data poses the risk that public information could become inaccessible if the vendor decides to stop supporting the software. Last but not least, there are privacy and fairness issues at stake. Acrobat is a totally closed-source program, which means we have to take Adobe's word for it that nothing sketchy is going on in its code. ... It would seem to be in the interest of the public for the government to prefer an open source solution, since it is much harder to hide nefarious features inside code that can be publicly inspected."

2 of 256 comments (clear)

  1. Horrible Summary: Some clarifications by Duckman5 · · Score: 5, Informative
    The application process required opening a PDF in Adobe Acrobat READER. It used some proprietary extension and if opened in any other application just had a note that said to use Acrobat Reader.

    When opened in Acrobat Reader it had a form with a button at the bottom to submit the information. He tried to process it using the most recent version of acrobat for each of the following operating systems:

    • On Linux, the button did nothing.
    • On Windows XP in a virtual machine, the button half worked (asked for login info)
    • On native boot Windows 7, it worked all the way

    The takeaway is this: a government process used a supposedly open format but ruined it by using a proprietary extension that only worked on a recent version of proprietary software running on a recent version of a proprietary operating system.

  2. Uploading grants is literally my job. by caution+live+frogs · · Score: 4, Informative

    I am an Administrative Official for a large organization. Uploading grants is literally a major part of my job. (As a research scientist, I also write my own grants - so I understand this from several angles.)

    The argument that open standards should be used is a fair one, but it is missing the bigger picture here. The vast majority of grants (NIH, NSF, Veterans Affairs, DoD, etc.) are SF-424 NIH standard packages obtained through Grants.gov and submitted by an AO such as myself, not by the applicant. Very few grants require the person authoring them to be the signing official who agrees on behalf of the organization to administer funds if the grant is successful. The vast majority of the applicants therefore route grants through a corporate or University network, where Windows (and to a lesser degree OS X - I'm a Mac user myself) predominate. In all of these cases, the organization will be providing the tools necessary - Acrobat is handed out like candy in my organization. It's part of the corporate image for all computers. Using Acrobat forms streamlines and simplifies submission for 99% of the applicants. The government is not going to change this to address a few edge cases.

    The suggested alternative - web forms - is laughable. It might be good for one person, but in an average submission cycle I am sending 10-15 grants with widely varying requirements including esoteric formatting issues, hard-coded naming conventions, and etc. - not to mention that the typical grant includes dozens of required components and attachments, each with set formatting restrictions. It is hard enough to comb through an assembly SF-424 package to check for errors prior to submission as it is. If I had to manually upload each of these grants, one at a time, one piece at a time, into a web forms system, I would not be able to do my job. Period.

    Post-submission, forms are processed by a clunky system in eRA Commons, then get referred to Grants.gov for eventual routing to the reviewing agency. The system has a series of automated checks built in to verify that the package is complete before it is assembled. This requires the various bits and pieces to be separate documents, as they are in an Acrobat package (and it is a package, with embedded attachments, not a flat PDF). This process is flaky and fragile enough as it is. Web forms are not going to improve the process, but they certainly would increase the workload for the AO by about 1000% and would definitely increase the error rate. This is also ignoring the fact that the forms are modular, in that some sections (like the budget) are only inserted as needed, and the necessity of being able to assemble and pre-check these things offline precludes any kind of web form system. The article writer is being intentionally obtuse and a bit naive here to make a shallow argument in favor of open standards. Heart is in the right place but reality is being ignored here.

    Tl;dr version: it's hard. We do the best we have with the tools provided. Just be glad Grants.gov didn't decide to use InfoPath instead of Acrobat.