
The People’s Code - jonbaer
https://www.whitehouse.gov/blog/2016/08/08/peoples-code
======
thewopr
Full disclosure, I'm in a federal department that has been pushing for more
open source for a while.

This is a great move by the White House. While there are a lot of groups that
are trying to push for more openness and release of software, it can often be
challenging. A lot of federal groups have been taught over the years to be
very risk averse, and open software is viewed by them to be risk. Probably one
of the most common concerns is, "What happens if someone takes and misuses our
software?" In a highly risk-averse federal environment, these can be
challenging arguments to fight against.

If you like and support this kind of thing, one big thing you can do is to
contribute and supply feedback. We frequently have to go to our superiors and
justify what we are doing with regards to open source. We say things like,
"this repository had X pull requests from non-federal contributors". Or, "We
got Y comments and questions from non-federal users of our projects".

It could be as simple as an email saying "Hey thanks, I found this useful", to
a full-on pull request fixing an issue or with a new feature request. The more
fodder we have to say "open source increases engagement and creates positive
feedback" the more you will see this kind of thing happening.

~~~
wang_li
I'm pretty sure that, assuming you're a government employee, any work you
create that would normally be covered by copyright as part of your job is
public domain. There's no license legally possible.

~~~
thewopr
Yeah, absolutely. We make that argument often. In fact, the software we open-
source is technically supposed to be released as public domain (as in, no
license applied) and often is if people are doing things right.

But that doesn't mean it has to be hosted and released online. Many agencies
work under the "not going to release anything until we get a FOIA request"
model. Just because it is public domain doesn't mean it is public.

~~~
toomuchtodo
Want my email address? I'll just send FOIAs all day long through Muckrock if I
know what I should be asking for (and pushing the results up to Github and the
Internet Archive).

~~~
fapjacks
I already FOIA the shit out of government. I am 100% willing to help FOIA the
right people for the right projects.

~~~
nwenzel
Serious question given that "data" is sometimes released from the govt in
tabular format in PDF:

How can you (or we) ensure your FOIA request for code isn't responded to with
a PDF of code?

~~~
fapjacks
Honestly, I'll take it. More than likely it will be something on a CD or DVD,
though. And if I get a PDF of 300kloc, then it's an indicator that I've hit
pay dirt, and they don't want me to see something, or are very reluctant to
give it up.

------
ideonexus
As a developer, I have been so impressed with the Obama Administrations
efforts to put _everything_ online. There is a .gov for anything now and I've
been watching organization after organization digitize our commons and put
them online.

This "Federal Source Code" policy is a great extension of the project-open-
data initiative released a few years back:

[https://github.com/project-open-data](https://github.com/project-open-data)

I found the db-to-api project in this repository incredibly useful for quickly
and safely exposing data from one of my applications to clients.

The only failing I see to these many many initiatives is that so few people
realize these powerful free resources are out there to be taken advantage of.
I hope that changes in the future.

~~~
Kluny
I just checked out vets.gov to have a snoop around, and it's mostly quite
impressive. But I found an SSL configuration error on this page
([https://www.ebenefits.va.gov/ebenefits/vonapp](https://www.ebenefits.va.gov/ebenefits/vonapp))
that will probably prevent vets from being able to use the site. Anyone know
where to submit a ticket about that? I got yet another SSL error from the
contact form on that page.

~~~
alexose
Hi! Vets.gov dev here. We're not in charge of VONAPP, but we work with them.
I'll see if I can't track down a good contact for this.

~~~
Kluny
Thank you!

------
swalsh
The cool part of this is it seems like there's a bunch of API's on here.
Perhaps that means I can submit pull-requests to get features that perhaps
previously that government would not have had resources to develop.

A good example, there's a recall API:
[https://github.com/GSA/recalls_api](https://github.com/GSA/recalls_api)

this is cool, I want to use it... I have an eCommerce website where I sell
food. It would be cool if I could be proactive in pulling items from my
product catalog. The issue is there is no UPC in the API, so there's no easy
way to correlate my products to recalled products. A cursory look at the
source code shows me the source:

[http://www.fda.gov/AboutFDA/ContactFDA/StayInformed/RSSFeeds...](http://www.fda.gov/AboutFDA/ContactFDA/StayInformed/RSSFeeds/FoodSafety/rss.xml)

if you open that up, a lot of the items have the UPC codes in there. This
gives me the ability to parse the details, and add the fields I need.

------
Roboprog
I ran into this last year: the feds set up their own "Bootstrap" type project:

[https://18f.gsa.gov/2015/09/28/web-design-
standards/](https://18f.gsa.gov/2015/09/28/web-design-standards/)

[https://github.com/18F/web-design-standards](https://github.com/18F/web-
design-standards)

~~~
vanderZwan
> _2\. Be accessible out of the box. We created tools that seamlessly meet the
> standards of 508 accessibility, from colors to code._

Very nice; this is especially important for government sites. It's even
printer-friendly out of the box!

------
Declanomous
I think this is great. Maybe the code won't be reused, but it adds another
dimension to governmental transparency, which is always a good thing.
Furthermore, any code produced by the government is effectively being produced
for the American people. We should have access to the code to use as we see
fit.

I wonder how this will affect bids for government software projects? Will
companies be upset that they have to open-source their software? Regardless of
whether an individual agency will use it, I can see the initiative saving time
and money, since programmers will know they can just find what they need in a
repository. If there is one thing you can count on, it's programmers and
government employees being lazy.

~~~
cpfohl
I'm thinking this will probably _not_ extend to the majority of code produced.
Intuitively, I'm guessing the military produces the most code of any branch of
the government. And I'm not sure i believe that we should all have access to
that code to use as we see fit.

~~~
Declanomous
I don't know which branch produces the most code, but military wouldn't be a
bad bet I guess.

I can see the downsides though, like somebody publishing code with keys or
credentials in it. That seems like a fairly likely error.

------
SmellTheGlove
Putting the code out there for other agencies to use is great, but getting
them to actually use it will be another battle. Reuse is tantamount to taking
away someone's budget, and therefore, status. The occurrence of two different
groups implementing very similar things entirely separately happens more often
than you'd think. And I'm not convinced they want to talk or work together,
because bureaucrat/military officer X doesn't want to lose budget/people.

~~~
evonfriedland
Of possible interest, I used the GitHub API a few months back to see what was
actually happening with the code government agencies were committing to GitHub
(reuse, contribution patterns, licensing, etc). I ended up writing up some of
my observations in a post [1] and 18F blog [2].

[1]: [https://emanuelfeld.github.io/blog/2016/04/27/government-
git...](https://emanuelfeld.github.io/blog/2016/04/27/government-github-
ecosystem.html)

[2]: [https://18f.gsa.gov/2016/06/16/emanuel-feld-talks-about-
his-...](https://18f.gsa.gov/2016/06/16/emanuel-feld-talks-about-his-
vizualization-of-government-github-organizations/)

~~~
SmellTheGlove
Really good work, thank you for sharing. Probably worthy of a Show HN post. I
wonder how this will track over time.

------
emilecantin
> This is, after all, the People’s code.

I've been thinking this for a long time, and I'm pleasantly surprised that the
US government now says this publicly. I hope this point of view becomes more
prevalent in the near future.

------
qwertyuiop924
As a person outside the government, I'm concerned about some potential
problems with this initiative:

For one, Pull Requests: If a government agency gets a PR on some code, I'm
concerned there may be pressure not to accept it: auditing requirements that
are so high that nobody wants to review PRs (not that audits are bad!), or
policies that otherwise don't encourage PRs, meaning that improvements don't
get back to the government.

Secondly, us winding up with a repeat of some of the problems that other
previously proprietary projects (namely, OpenSolaris) encountered: The code
that was opensourced being dependant on code that, for whatever reason,
_couldn 't_ be opensourced, hampering forks, and further development outside
of the organization that developed the software in the first place.

Even if issues like this, or issues that I haven't even thought of, occur,
this is a huge step forward.

~~~
ajdlinux
I was recently discussing open source policy with a friend in the Australian
Government whose agency is working on a whole-of-government standard that
encourages open source.

She told me that many departments who don't currently have much experience in
open source express the concern that if they open source their code, they've
got to deal with all the issues that come with maintainership of an open
source project.

Her opinion, though, was that the first and foremost reason for encouraging
agencies to release their code is transparency and accountability - it's
taxpayer money, after all - and that even chucking up a plain old tarball is a
great start. As for running an open source community - well, cross that bridge
when you get to it. It's entirely possible that no-one actually cares about
contributing to your codebase. It's entirely possible that you're not going to
have to deal with contributions larger than typo fixes. If you do end up
getting larger contributions, write your policy and your process when you need
it.

If you're in the parts of government that are encouraging a move towards
openness, tell other agencies that it's fine if they don't have a fully
developed open source strategy. Get their code up on GitHub somewhere first,
prove that the sky won't fall in, and just get them comfortable with the
concept of open source. Once we've achieved the first objective of getting
source code out in the open at all, then we can worry about the rest.

------
fludlight
This is cool, but can we call it something else? The People's * is a prefix
used by totalitarian governments.

~~~
heygiraffe
> The People's * is a prefix used by totalitarian governments.

Indeed. And so are words like "homeland".

The last ~2 decades have seen a widespread change in ideas about the
relationship between the U.S. federal govt. and the people. As a result,
practices that were once restricted to highly repressive states are now merely
a bit controversial in the U.S. And then we also have these ways of naming
things that you & I noted.

So I wonder: could it be that _thinking_ more like a totalitarian somehow
naturally leads one to _talk_ more like a totalitarian?

~~~
Retra
I keep watching older TV shows that aired when I was in the military and they
keep using the term "War on Terror", which frankly, is something I'd never
directly heard in the military (only from politicians) and it's surprising to
me that anyone would say such a thing without reactively slapping themselves
for gleefully eating up such confusion-inducing propaganda.

I think some people just _like_ talking like that.

~~~
dTal
Another one to watch for: "bad guys". It's such a common phrase in America I
think people are numb to how thought-stopping it is. TV shows, cops, defense
contractors, everyone's eager to nasty things to "bad guys" (but it's okay,
see, because they're _bad_ ).

A _definitional_ enemy. Very newspeak.

------
rm_-rf_slash
As helpful as this may be, the real transformative code is often proprietary.
As others have mentioned here, not everybody will use every reusable
component, whether it be because of ignorance, larger system incompatibility,
or simply turf protection.

We should look into solutions for intellectual property that are based on an
information economy instead of an industrial economy.

Personally, I think it would make sense (perhaps more for pharmaceuticals than
software) to significantly shorten the time a patent is valid and/or strip the
protection of monopolistic production rights, and instead allow the free
market to sell the product at the lowest cost it can be made at, as long as
there is a royalty fee. How the fee is determined, I'm not sure yet.

Still, it's clear that our IP system is creaky, overcomplicated, and is tilted
too far in the direction of big business, lawyers, and patent trolls, instead
of the actual inventors and consumers.

~~~
notduncansmith
Not sure why this comment was downvoted. I feel similarly about IP reform, and
would love to see more discussion around how we can reward innovators
appropriately for inventing things without artificially limiting the
production of those inventions (via patent trolling, royalty fees, or any
other mechanism).

If the issue is that inventors want to get compensated for their inventions
(to a degree commensurate with their value), but we don't want to limit what
the market can produce, then maybe we could imagine an IP-buying group that
paid a fair price to inventors and then made the IP available for general use
among the financial backers of said group. One could imagine this as a
governmental function (distributing purchased IP among taxpayers) or a
corporation (s/taxpayers/shareholders), and it appears to me[0] either one
could fit within the framework of existing IP law.

[0] I am not a lawyer and have no idea if this is true.

------
clarkmoody
Avoiding duplication of source code across Federal agencies is nice, but it
would be better to eliminate _duplicate agencies_ and functions within the
bureaucracy.

------
nsx147
Check out this guy's commit history: [https://github.com/alex-perfilov-
reisys?tab=overview](https://github.com/alex-perfilov-reisys?tab=overview)

~~~
brobinson
[https://github.com/ben174/git-draw](https://github.com/ben174/git-draw)

------
batbomb
I'm very familiar with the Department of Energy process, and there are a few
considerations for every lab in the DOE.

TL;DR: The DOE encourages open source software, but it isn't default and
there's some (low) barriers.

In general, though, what you can do with your (non-export-controlled) code
consists of (in order of increasing difficulty):

1\. Nothing. Keep your code private. If you'd like to stop maintaining code
but want to make sure it sticks around, the DOE has a software library, the
ESTSC, in Oak Ridge (a division of OSTI). It may also be the case that the
entity running the lab wants to claim ownership.

2\. Open Source. Due diligence is needed to ensure funding agencies and MOUs
are respected. Copyright is typically assigned to the contractor running the
lab in question (i.e. for Berkeley lab, -> Copyright goes to UC, SLAC ->
Stanford, etc...). Major international collaborations can be a bit tricky
because foreign countries have their own rules. I think more work needs to be
emphasized on this front going forwards.

The DOE also wants to track the popularity of Open Source software, namely
downloads. GitHub has met their requirements for reporting.

The DOE discourages use of the GPL and similar licenses. The reason, as I
understand it, is due to the fact that the Government (i.e. Defense) must be
able to use and modify software (and give to contractors, etc...) without
falling under any additional burden. I believe the BSD license is preferred
most widely across the labs.

In some cases, people at labs do release software under GPL. If they didn't
get special permission, they are likely violating their lab's contract with
the DOE.

3\. Commercialize. This is really hard. You have to first perform market
research, establish the market, spin off, deal with SBIRs, etc... This is a
high barrier.

I've been personally working on streamlining the process for (2) with legal
for my lab, so that anybody can open source their software very easily,
hopefully by just filling out a web page. I'm hoping the recent white house
directives help eliminate some of the bureaucracy involved in the process.
I've also been trying to reduce fragmentation across the lab. The lab has
never offered an official SCM platform, and grad students/postdocs are
notoriously bad at keeping important source code in their personal GitHub and
then leaving after some time.

It should be noted that almost all national lab facilities are effectively ran
under contract, so nearly all national lab employees are not actually federal
employees. So we do have a slightly different set of rules.

Finally, there is already a decent presence on github and bitbucket of labs,
in case you are interested:

[https://github.com/LLNL](https://github.com/LLNL)

[https://bitbucket.org/berkeleylab/](https://bitbucket.org/berkeleylab/)

[https://github.com/slaclab](https://github.com/slaclab)

[https://github.com/NERSC](https://github.com/NERSC)

[https://github.com/sandialabs](https://github.com/sandialabs)

It should be noted this is an extremely, extremely small slice of the software
that drives experiments, projects, and research in the lab. Many times
software belongs to the project/research group, so there's likely a project
github organization where the code naturally resides. This is sort of a
consequence of labs becoming more and more multi-disciplined, i.e. the science
missions of labs like SLAC and Fermilab are no longer aligned primarily around
their accelerators.

OSTI is supposed to maintain an index of that software if it's reasonably
important, but it's not really enforced.

PS: If someone from USDS/data.gov/18f can and would like to help out with this
in any way, I'd be happy to collaborate!

------
afarrell
I wonder to what degree this applies to the DC city government and if it can
be made useful for municipalities generally.

~~~
evonfriedland
The DC municipal government actually has a Github organization
([https://github.com/dcgov](https://github.com/dcgov)) and has been attempting
to pilot open source development ([http://open.dc.gov/open-source-
guidelines/](http://open.dc.gov/open-source-guidelines/)) throughout the city.
I helped write that document, which was inspired by/borrowed from 18F policy.
Take up has so far been limited, though some agencies have been using Github
Pages.

------
JimLaheyMD
How about we start with the source code for electronic voting machines?

~~~
solidangle
And how would that help? How do you know that the code they published is the
same as the code installed on those machines? You need voting machines that
leave a paper trail (which the voter can verify while voting), that way the
machines can provide quick results while the final results can be counted by
hand.

~~~
ConroyBumpus
We had them, for decades. They involved the use of punched cards and a
butterfly ballot. The voter could physically inspect the ballot to determine
which holes were punched. Sadly, the "hanging chad" of Bush v. Gore (2000)
pushed many states into using electronic machines, with predictable results.

