20% of code && open source by default?

[mathisonian]

The introduction states one consideration as being:

Would an “open source by default” approach that required all new Federal custom code to be released as OSS, subject to exceptions for things like national security, be more or less effective in achieving the goals above?

At an (extremely) broad level open source code can be split into two categories: (1) code which is fairly self-contained and not likely useful to others outside of some purposes like education and the ability for users to provide feedback or things like typo fixes directly to the developers; and (2) code which is modular and meant to be consumed by other users.

For several reasons I would suggest that no, an open source by default would not largely help to meet the stated goals of "fuel innovation, lower costs, benefit the public, and meet the operational and mission needs of covered agencies".

Most code which is written by developers falls into category (1) above. While there is an argument for making this type of code open-source-by-default, it doesn't entirely make sense because,

• This places an additional burden on developers (for a website to be open source they have to take time to separate application code from any private keys, passwords needed for deployment, etc).
• It mostly adds noise to the open-source ecosystem. I'd rather see a few useful libraries be open sourced than 20 ruby on rails apps. There are plenty of existing examples to learn from in most cases.

One metric that some companies use, is that if they see the same code being re-used across multiple projects they see that as a library and will either open-source it or modularize it for easier internal use. I could see this as being useful for government work, especially when sharing code across agencies or branches.

Maybe a useful heuristic would be: where feasible with respect to national security, if one government agency wants to re-use code that another has written the mechanism for doing so should through open source.

[mathisonian]

Following up on this, the proposed "covered agencies to release at least 20 percent of their newly-developed custom code" seems to me like the wrong approach.

For (1) it is notoriously difficult to quantify the size of a code codebase. For (2) it is a metric that will encourage people to open-source code for the sake of open-sourcing it rather than for the sake of sharing useful code with the community.

I see the final point in my previous comment as being a much more reasonable way to approach this.

[AllenDowney]

Agreed that 20%, or any other arbitrary threshold, is unlikely to work well. OSS by default seems like a better starting place, and your heuristic:

where feasible with respect to national security, if one government agency wants to re-use code that >another has written the mechanism for doing so should through open source.

is a good start. The next natural question is what other conditions there might be for overriding the default.

[willbarton]

This places an additional burden on developers (for a website to be open source they have to take time to separate application code from any private keys, passwords needed for deployment, etc).

I can speak as someone with experience with open source projects (including the OpenDarwin project, which failed because of arbitrary openness), and as an employee at CFPB, where everything we write is public domain by default. This is false. There is no additional burden to developing in the open versus closed, and, in fact, the transparency has many benefits.

It forces us to be more mindful about following best-practices, particularly when it comes to what we commit and don't commit to public repositories. And, to ensure we don't do something stupid, we have a handy utility called Clouseau that checks for obvious patterns and works nicely as a git commit hook.

It mostly adds noise to the open-source ecosystem. I'd rather see a few useful libraries be open sourced than 20 ruby on rails apps. There are plenty of existing examples to learn from in most cases.

The open source ecosystem, in my experience, thrives on the noise. It is as vibrant as it is because people write code in the open without knowing whether it'll be useful to anyone else or not. The advantage of an open-source-by-default policy is that it encourages us to look at the problem space in terms of how our solution could also benefit others. It forces community-oriented thinking as we're developing, which I think is useful when we are developing for the benefit of the American public.

And if it isn't useful to anyone else? The absolute worst thing that can happen is that no one else uses it. That's the guaranteed result if we develop in the dark and keep the resulting code in the dark: the code will never be used by anyone else, inside or outside of government, whether it is potentially useful or not.

I do think 20% is arbitrary, and could result in some arbitrary code release to meet a minimum standard, but I want to push back a bit on the idea that open-by-default is in some way burdensome.

[mathisonian]

Good points @willbarton. Regardless of my opinions of the merits, it is clear that 100% open-source is much better and more practical than 20%

[danawoodman]

Open source by default, in my opinion, is the right choice.

From a political perspective, having the code that taxpayers fund be open source is a great thing. It creates a level of transparency otherwise not possible and prevent situations like the healthcare.gov fiasco. Open source forces a level of accountability on the developers of federally funded software that doesn't exist today. This accountability is critical to ensure that the American public get the best possible software for their tax dollars.

To me, it is an afterthought to have this code be re-usable in my own projects or those of others. While this would be a great sideeffect and tends to happen when you have good software development practices, to me the critical thing is more transparency of what is being built for the US government with our tax dollars.

[davimack]

Open Source by Default, with a process required to exempt something from being open-sourced.

I think rather than focus upon percentages, the policy should 1) remove barriers to open-sourcing code, and 2) should add disincentives to keeping the source closed. The barriers I'm thinking of are similar to those to do with classification of information - there's a penalty for getting it wrong, so more is classified than really needed. The same thing could be taking place with regards to Open Source: your developers may be uncertain and fear reprisals if they open-source something which is then later questioned.

I think the disincentives to keeping it closed source should be embedded within the practices of the development teams - rather than using private repositories for code, public repositories should be used (although, yes, this does present security concerns, particularly with regards to passwords embedded w/in config files, etc.). In other words, make it difficult to have a private repository, perhaps with a process to justify the need for the private repository, and have everything else default to open.

If the end goal is to get 1) more eyeballs upon the code in use, 2) more code reuse, 3) community participation, and 4) more of the appearance of being open, then you need to open-source the code.

[ocdtrekkie]

It's amazing how often something assumed to be small, insignificant, and useless to others can come in handy. Sometimes you're looking for something obscure, that nobody else thought anyone else would need. And often, tutorials and advice on code sites have weird licenses attached. The more code that can be put out under an OSI license the better. Things like GitHub stars are a easy and functional way to make the code most useful to the public drift to the top of the pile.

[ocdtrekkie]

Also, I'm willing to bet a lot of people would take interest in even some of that government-useful-only code in the sense of debugging and improving. It wouldn't shock me if this became yet another form of public service! To help the government improve speed and security of their code.

[davimack]

No doubt having the public involved could be significant - I'm thinking of, for example, even something so simple as reviewing the code & commenting. It would improve the code quality, no doubt, and hey - we already get in here and fix code that's of interest to us, and how much more of interest to us can you get than the code that makes the government run?

[normanbrobinson]

I would recommend a default to 100% open source. Default implies Major IT Investments (OMB e300 and 53 reporting; ITDASHBOARD.gov) should include tracking use of and reporting of licenses for software used with specific alignment to capitol planning and program reporting to require justification for not using open source licensed software.

[jessebeach]

I agree with @willbarton about the notion of 'extra burden'. Keys, inlined passwords, sitevars, globals -- playing fast and loose with these aspects of software leads to subtle bugs and attack vectors. It should not be considered a burden to separate application logic from these sensitive application state values. It's good practice and taking an open-source first approach promotes it.

As soon as we allow for a protected & secret status for some code, it will either be used to hide poor development practice or worse, hide malicious code.

[linguistbreaker]

@jessebeach @willbarton The openness can indeed enhance security! +1

[emartinez-usgs]

I agree with much of @jessebeach and @willbarton comments and personally strive for best practices when developing software. Yet while I feel a target 100% is an ideal goal, setting a minimum percentage (20% being very arbitrary) is a restriction that itself can stifle innovation.

The fact that the majority of comments in this thread have supported the 100% goal (or open by default) makes it seem the culture of OSS is already pervasive among developers. It begs the question, do we need a policy forcing 100% OSS?

More simply, if a national policy could simply remove impediments to leveraging existing OSS hosting solutions (like GitHub etc...) the development community might embrace the opportunity (National Security and Public Safety concerns aside) to move to Open Source and naturally meet the 100% goal.

[esplinr]

I appreciate @mathisonian kicking off the conversation, as he raises some common concerns with an open source policy. It is worth looking at his classification of projects into two categories:

1. Code that is unlikely to be useful in other contexts
2. Code that is designed up front to be reused

The fundamental challenge is that it is difficult apriori to determine which category a specific project will inhabit. You don't know what will be useful to me.

He raises two concerns:

• The concerns about an open development process creating a burden for developers does not ring true to my experience. Any effort our teams spend in configuring for open development is compensated by the value of knowing the code will be public and be tied to one's reputation. It takes extra effort to follow best practices, but on average it is worth it in the end.
• The concerns about adding noise to the open source ecosystem rises from a narrow view of how code gets used. We live in a long tail world, where there are effective tools for sorting the relevant from the irrelevant. It is impossible to decide upfront how my signal will differ from your noise. For instance, think of the academic research that can be done with a nearly complete corpus of government code; the doctoral dissertations that will be written will benefit the entire industry.

I agree with @davimack's proposal: the right approach is to require open source by default, and have a carefully controlled process for exceptions, with the reporting requirements suggested by @normanbrobinson to give it teeth.

To answer @emartinez-usgs's question, the value of a requirement is that certain players in the industry want to keep their code private and will look for loopholes in order to do so. They want the taxpayer to pay for poor quality, and they want to repeatedly sell the same solution. That is why we need a clear policy with provisions for enforcement.

[chrisodva]

One problem with an arbitrary minimum goal such as 20% as it will allow an avenue to do the minimum (20%) and check off the mandate as achieved. The way to maximize the effectiveness of this effort is to put the extra burden on anybody wanting to do anything other than open source their project. So all taxpayer funded development should default to open source, with the "burden of proof" on those parties wanting to do something other than open source development.

[DruidSmith]

I agree with the open-source-by-default philosophy - the code was funded by taxpayers and should be made available. As to the usefulness of the code, that's in the eye of the beholder. However, that said, it would also be helpful to promote a set of patterns and practices in government software development that specifically promote modularity and reusability, along with patterns and practices that leverage existing open source code bases, and which can help to extend and improve existing open source code.

[stevenhaddox]

@mathisonian I have to discuss one of your main points for not supporting open source by default:

This places an additional burden on developers (for a website to be open source they have to take time to separate application code from any private keys, passwords needed for deployment, etc).

Anyone who is writing their code in such a way that they have private keys, or passwords needed for deployment directly in their code base is absolutely doing it wrong. I don't make many strongly opinionated stances that I also hold strongly, but this is one of them.

If you are writing professional code and are being paid by tax dollars to write it, then you should be doing it the right way. You should be abstracting deployments into a completely separate process (whether that is a CI server build & deployment, capistrano ssh deployment, or devops tool for deployment), or at the very least symlinking anything related to configuration credentials separately from your application code base.

For further reading I suggest looking at the twelve factor app, specifically it's config section.

Anyway, for all of these reasons I strongly feel that open source by default would be a huge benefit in that it will require government (and government contracted) developers to think about writing cleaner more sustainable code (and that's in addition to the obvious benefit that others can benefit from the code we are all paying for as well).

[stevenhaddox]

@emartinez-usgs: in response to your comment:

The fact that the majority of comments in this thread have supported the 100% goal (or open by default) makes it seem the culture of OSS is already pervasive among developers. It begs the question, do we need a policy forcing 100% OSS?

I can attest to the fact that we absolutely need an open source by default position if we want to see open source code coming from the government. I've worked on government contracts most of my career and there is a very strong desire to never distribute unless absolutely required by default in the community. Whether it's due to developers not feeling confident about the cleanliness or security of their code, laziness, or the fact that the government is too important to need to share, there are definite internal biases that will prevent open sourcing things because it is the "best practice" as they often feel best practices are not applicable to them.

[johnmod3]

100% is not possible (or desirable), but the default should be to release all gov funded source code as OSS UNLESS there is a compelling reason not to. The waivers granted should be posted, made publicly available and probably have a time to live, until the code shall be opened up

[themightychris]

Aside from whether code is useful to other people, I think the biggest argument is sovereignty. If taxpayer money funds the development of an IT system that becomes a part of public infrastructure, no private entity should have a monopoly on understanding or servicing that system. And I mean both the legal monopoly that comes in cases where a vendor retains copyright without granting an open source license, and the effective monopoly that comes from keeping something vital and complex opaque so no one else can practically critique or make improvements.

Another consideration that seems overlooked here so far is that the future open source community will include more governments. A state-scale pollution inventory system might not seen useful to the current open source community, but other states and countries could certainly make use of it and share any improvements they make/fund. When it covers to government operations, collaborating on open source solutions in the public domain between governments will produce far better outcomes than the current model of proprietary vendors building lowest-common-denominator solutions they can rent to many jurisdictions while minimizing investment

[davimack]

If there isn't a clear policy, I'd worry that developers would err on the side of cautious and not open-source. We need a clear policy which states that open-sourcing should be by default, rather than by exception. We also need to have this carry through to contracted companies, particularly because we the people have paid for that code and should have a right to see it.

[xmlwerks]

All code submitted in Govt. contracts should be the property of the Govt., and available through FOIA or other methods -- except that's not practical in all circumstances, indeed many. But, for example, if you get a NSF grant, your data is NSF / public property. But what about security? (not just for sensitive files, but for sensitive algorithms?) Sometimes a little obfuscation can get you even a day or two in order to address exploits. And how useful is source code without documentation? Some Govt. agencies use Google Docs and email -- should Google be required to publish that code, make it public? Govt. specifically awards contracts in categories to small businesses, women owned businesses and other supported categories -- so will these be required to "package" together from open source libraries (only), or can the Govt. make the investment to have unique solutions? healthcare.gov was critized by the NYTimes because it didn't use standard SQL -- will that be the effect of open source, a few open solutions considered acceptible and unique, if closed-source, solutions are not? And what about Open Standards? Is Oracle SQL an open standard, because it is certainly ubiquitous.

[ocdtrekkie]

@xmlwerks There is a huge difference in third party software being purchased, and code being developed for the government. Code being developed for the government is development work paid for by taxpayers. And it's actually in both the government AND the citizens' best interests to use open development.

And 'security by obscurity' ISN'T security, and that line of thinking has led to many government security blunders. Discouraging security by obscurity, by open sourcing code, will actually help ensure the government writes better code, and that vulnerabilities in it are found quickly.

[johnmod3]

[thomasrive]

All new Federal custom code should be released as OSS. Either disincentivizes sloppy coding or gives public coders practice in searching for bugs.

[xmlwerks]

@ocdtrekkie thank you for replying. OK, purchased software, you are saying, is different, so we purchase Oracle, and develop a massive system in Oracle or any system, and even if the source code is open and available, it becomes problematic to move to another vendor, as developers utilize the unique features and aspects of that system. So,I am saying, that open source is one half, the other is Open Standard. But I'm not completely convinced on open security software - it's great when problems are caught before they are in production, but when errors get into releases, but errors make it into the public. OpenSSH was the gold standard, and everyone assumed, because it was open, that it was error free, until it was found not to be, and the error and the actual code itself was available and anyone could read it and code against it. Wordpress is the most open and widely used software ever, and it's terrific, until it has a vulnerability, and it has had many and they have been severe. So, what I am saying is, I think it is fair for govt. entities to treat security software differently, where they might want to reveal little, or a little at a time, after various rigorous testing, because I am not convinced that the source code should be open to the public. At the same time, Govt. must be open with us, not deliberately recommending weak standards.

[ocdtrekkie]

@xmlwerks Bear in mind that state-sponsored attacks from intelligence agencies have almost unlimited resources to poke and prod software and networks to find vulnerabilities. In light of that, we have to bring an incredible amount of resources to bear on protecting our country. Why limit ourselves to internal government employees? Our government should be tapping into the resources of the development community for help making sure what we do is up to snuff. There's some incredibly talented people working for the government directly, but vastly more amazing talent available outside of government. And by publicizing released code on communities like Hacker News, there's a good chance we'll get some great people involved.

OpenSSH's problem wasn't that it was open, the flaw was that not enough eyes were reviewing the code. Strong open source development requires that we do our part to check and verify what is out there. And there's a lot more attention on OpenSSH now than there was before. And consider things like Flash Player, Microsoft Windows itself. Still security issues on a monthly basis. A zero-day attack on Flash was discovered just this last week, and it affected Flash Player, Microsoft Edge and Internet Explorer... Closed software definitely isn't any safer.

[rafael5]

+1 100% open-source by default. Waffling on this by pretending there is some magic number or % will only leave contracting officers wondering, project managers confused, and leave massive holes in government contracts that vendors will drive a mac truck through. For example, even if the contractors provide 99% of the code back to the public as OSS, that 1% of code that a vendor witholds from the government is enough to render the software broken and useless. So it has to be unambiguous: 100%.

+1 for establishing coding standards and conventions that allows easy division of logic from data, which will allow for automation tools to do redaction of potentially sensitive information embedded within programs (such as tables of customer data, tables of SSNs, etc.). This would allow replacement of this sensitive information in a table with another table of sample data. This would allow the redacted verssion of the software to run successfully and not break the software. This is in contract with embedding sensitive information inline within the code. So the only way to redact this information is to also redact those sections of code, which would break the redacted verison of the software.

[malanthomasii]

I agree that an open-source presumption should be used, similar to the (nominal) transparency presumption in FOIA requests; the exceptions framework is robust enough to shield what can't be released. Also, percentage targets are likely to lead to minimal-effort-seeking effects (i.e., performing the least work required to meet the minimum threshold), as has already been stated.

Generally speaking, if you think open-source releases are going to promote a certain good, more of them are unlikely to reduce or obscure that good.

[curtosis]

It really probably must be open-source-by-default for it to have any meaningful impact. The sovereignty argument is a strong one: it's difficult to justify maintaining private rights in code developed at taxpayer expense. The exception mechanism is there for sensitive code, as long as it's not abused to protect "trade secret" code.

The exception mechanism should also be 100% public. It's perfectly reasonable for the government to protect the code to sensitive systems; it's in most cases not reasonable to protect the existence of such systems. There are, of course, limited circumstances where the existence of a capability is sensitive, but these should be extremely rare, and largely limited to intelligence applications. By and large, if a system affects the operation of government -- and particularly if it affects how the government interacts with its citizens -- the existence of the system should be public, even if the code needs to be protected; and the granting of exceptions should be transparent and public.

Example: it's absolutely expected that the IRS protect the systems it uses to audit tax records; I don't think it's unreasonable to list it in a register along with its OSS exception certification (similar to the existing SORN mechanism, though that has a narrower application and can also be improved).

[mikeBeviBevi]

@themightychris Great comment.

I wonder how the 100% open source, extended to contracted work, affects our economies? I'd like to attempt to play devil's advocate for a moment. Hypothetically, what if companies are not willing to release their work under a public licence and what if there is not a community that is actively developing to a particular project that has a deadline to meet? This could make it difficult for the government to get quality work, having to rely on unproven companies that would be willing to release adhere to this policy.

Simply taking the cheapest option can backfire and and waste more resources in the long run. I would think/hope in the long run that by enforcing the 100% instead of the 20% it would force companies to take up a new business model that is lucrative to the tax payers without hurting the government contracting economies.

[davimack]

Hypothetically, what if companies are not willing to release their work under a public licence...?

I'd just say that, as the government is a huge player, they could get their way without much fuss. Yes, there will be some who object to exposing what's under the covers of their products - and that's fine, they can bid on new work and actually do the job right. Just think, though, what sorts of code has been hidden behind the veil, as it were.

Getting eyes on code is a strong motivator for developers to write good code, and is a good way to ensure the government gets what it's paying for. It also asserts the ownership of the code - we, the people, who paid for it.

[rafael5]

".... hypothetically, what if companies are not willing to release their work under a public licence...?"

=> Simple. Their bid on the project would be disqualified. There will be more than enough smaller, smarter, more agile companies more hungry for work.

This is clearly something that the traditional beltway contracting firms will hate. Shining light on the code that they actually deliver will force them to actually deliver.

Rafael

Rafael Richards MD MS 202-469-1527

On Wed, Mar 16, 2016 at 10:27 AM, davimack notifications@github.com wrote:

Hypothetically, what if companies are not willing to release their work under a public licence...?

I'd just say that, as the government is a huge player, they could get their way without much fuss. Yes, there will be some who object to exposing what's under the covers of their products - and that's fine, they can bid on new work and actually do the job right. Just think, though, what sorts of code has been hidden behind the veil, as it were.

Getting eyes on code is a strong motivator for developers to write good code, and is a good way to ensure the government gets what it's paying for. It also asserts the ownership of the code - we, the people, who paid for it.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/WhiteHouse/source-code-policy/issues/12#issuecomment-197354108

[mikeBeviBevi]

@davimack disclosure, I have been employed as a fed contractor as well as a fed employee and it has been my experience that the majority of developers on both sides would very much like to share their work.

There is work is done on operational systems that I think would be of particular interest to the public, however, there are many that are weary that certain, safety critical systems have a greater chance of being exploited if their underlying code were released. I think the first reaction of many of the managers of these systems is to go for the exception. It would be great if we could make a strong enough argument that the safety of these systems would see a greater benefit from public transparency rather than current policies.

@rafael5 You are absolutely correct. That was what I was alluding to. I hope that the smaller smarter companies are up for the task.

[johnmod3]

part of the problem is that gov contractors think they are going to create some valuable set of IP working off of taxpayer funding. I'd say under 5% of that could be considered unique + as OSS continues to make inroadsGov systems will become more open just by evolution

[danawoodman]

I'm going to reiterate my pervious point because I think it is perhaps the most relevant to deciding why/how to open source government software:

Open sourcing software that is paid for by tax dollars in the US fosters a level of transparency and accountability into the system that would otherwise be impossible. Preventing HealthCare.gov fiascos should be a top priority for the federal government and making code open would go a long way in doing that. Transparency into where our tax dollars go is a critical step to ensure an open government.

[DruidSmith]

Open source by default, with a documented justification process for not providing it as open source.

[mikeBeviBevi]

@rafael5 I'd like to continue that line of thought. I wonder how the outlook for programming jobs changes when the large companies are not bidding for this work. I think that if you talk to any young person looking to pursue a job in STEM fields, their aim is to work for the tech giants of the world, in part because they want to make as much money as they can. Smaller companies cannot offer the kind of salaries that these larger companies can. So will the government end up losing out on talent that used to be working on these projects? I know it's not all about the money but, they still have loans to pay off, right?

[johnmod3]

@mikeBeviBevi in the federal contracting space salaries are pretty competitive since they are pass thru to the government among small to big companies (big ones do have more benefits though).

[themightychris]

@mikeBeviBevi When large companies aren't bidding for this work, more of the funds will ultimately be going to the craftspeople building it than outsourcers, middle-managers, and lawyers. Smaller technology companies bidding on big public projects in cohorts will produce better results, cost less, and be better for the economy. Smaller companies will outsource less and invest more in local talent through things like apprenticeships. All of this is made possible by prioritizing openess in code and process

[mikeBeviBevi]

Makes sense to me, thanks @johnmod3 & @themightychris

[technologiclee]

All government code should be open source. I think the 20% should be 100%. If it is funded by the public, it should belong to the people to see and use.

[richsalz]

Strongly agree, default should be open (PD FOSS BSD whatever) and contractors must provide a compelling reason to keep it proprietary.

The financial incentive -- let the contractor keep it so that they can sell it and build a market and create COTS offerings -- is outdated. Open source is the new financial imperitive.

[rafael5]

I agree. The best and brightest programmers with highly specialized skills are recruited by the likes of Apple, Uber, Facebook, LinkedIn, Google, etc.

Very low down on the priority of any computer scientist or engineer would be to work for the government, or government contracting company - with all of the horrific regulatory and management layers that stifle innovation.

The point I was making is that we need to replace the usual Beltway Contractors (The Too Big To Fail companies that have consistently failed to deliver on any large government software project) with the small, scrappy, smart West Coast developer companies.

For example (as you pointed out): What company ended up saving the $650M Beltway contracting software fiasco called Healthcare.gov? It was two or three guys from a well known West Coast company.

Rafael

On Thu, Mar 17, 2016 at 8:50 AM, Michael Bevilacqua < notifications@github.com> wrote:

@rafael5 https://github.com/rafael5 I'd like to continue that line of thought. I wonder how the outlook for programming jobs changes when the large companies are not bidding for this work. I think that if you talk to any young person looking to pursue a job in STEM fields, their aim is to work for the tech giants of the world, in part because they want to make as much money as they can. Smaller companies cannot offer the kind of salaries that these larger companies can. So will the government end up losing out on talent that used to be working on these projects? I know it's not all about the money but, they still have loans to pay off, right?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/WhiteHouse/source-code-policy/issues/12#issuecomment-197865135

[johnmod3]

@rafael5 is wasn't 2-3 guys who saved it, is was an injection of a 1/2 billion dollars after launch and an all hands on deck mentality. Also the blame is shared equally between client and contractor. Having been thru a number of gov contracts, the number of things the Gov makes you do (even when you tell them it adds no value, just wastes time and money) is idiotic.

[xmlwerks]

@rafael5 An NYTimes article pointed to Healthcare.gov decision to use noSQL - MarkLogic - as a reason for it's failure. In fact, that piece was not re-architected and HealthSherpa was able to use the API to write a simple age+sex+zip-code app that would give you a price range and list of insurance companies. The Times faulted them for NOT doing things the same old way.

Are we saying that the project would have been a success if it used mySQL? Surely the problems were much more complex than that, including court challenges, funding threats, political issues when any specifications were released.

Last week, we saw how one open source Node.js contributor could break the builds of thousands of programmers.

The "cutting edge" companies you mention don't really do any financial programs. They get to release features under "beta" they get to release on their own schedule and user's (even if just a few) can be guinea pigs whose feedback decides of features live or die. That is a million miles from an operation where expenditures are scrutinized and become political fodder. Would you really want Facebook to make your accounting software?

At least recently, the Govt. allows and promotes Agile - they want cyclical development with feedback. That's huge, because it used to be, I know someone who's job it was for a while, to write legal challenges to contracts to force more payments for "changes from original proposal".

Of course anything written for the Govt. is their property, and of course it should be available to the public to the greatest extent possible that does not compromise security, etc..

But some companies have invested in proprietary solutions -- that work. For example, should Google release the source to their search engine? So should Govt. NOT use Google because it's not OS?

There will always be a buy/build decision, and the rule of thumb for Govt is to utilize the private sector rather than build up in-house. If you ONLY have open source contributors, you may not get the legal commitments or responsibility the public, and legislators, expect. If you require every project to be open, you may not be able to attract private sector contractors who have very good solutions -- that they don't want to give away..

Let me know if I owe the list some potatos.

[ocdtrekkie]

@xmlwerks Arguably, given that Google's search engine algorithm could determine the outcome of the Presidential election[1], Google should probably be forced to release their source. But that's neither here nor there and not really the point of the discussion. [1] http://www.politico.com/magazine/story/2015/08/how-google-could-rig-the-2016-election-121548

There should always be a cost/benefit analysis for sure. Anything the government develops or outsources development of, should be a better deal for taxpayers or a better product fit (ideally both) than existing proprietary solutions. But anything the government pays to have developed should be open sourced. Seeing the price of enterprise software today, I think there's plenty of room for developers willing to work in open source to beat existing players on price.

I do echo your notion though, that overglorifying Silicon Valley developers is a bit silly, Silicon Valley companies waste more money than most of us will ever encounter in our lifetimes. Dozens of companies in Silicon Valley go bust every single month. It's not a level of recklessness suited to government work.

[xmlwerks]

@ocdtrekkie Hopefully M$'s Tay won't be released on Google, considering what Twitter's done to her.

Governments in Europe are seeing big savings and requiring open source. But it doesn't always work. What is also required is Open Standards.

http://www.computerworld.com/article/2497659/government-it/berlin-rejects-open-source-plan--looks-to-open-standards-instead.html

So I continue to believe there is a place for vendors, COTS, etc., because sometimes, you need a point of contact and a person/company financially and legally liable for delivery. Also this, if you develop something, then contribute it to Open Source, while on a Govt. contract, then you get audited, and the GAO says "well, the contract never called for this to be made, it was never requested, we don't think it added sufficiently to the core value..."

I'm trying to be "good coach" which is one who will tell you everything you are doing wrong -- not that anything said in this conversation is wrong. Hopefully, this isn't naysaying only feedback on where to keep your guard up.

[ocdtrekkie]

Poor Tay. She was too young for the Internet.

I will say I am generally okay with closed source software if I know I can get my stuff between it and a competitor easily. So "open standards" is definitely a valuable key. But I think the goal here is less about interoperability (as good as that is) and more about ensuring software the taxpayers pay for development of is available to everyone. Arguably, depending on the nature of that software and it's usefulness to others, that could be a part of the ROI.

[david-a-wheeler]

I also recommend "open source by default for software developed using government funds". If "we the people" paid to have it developed, then normally "we the people" should get it. There will need to be exceptions, but those can be handled by a waiver process. There's always a default - the question is, should the government default to transparency and collaboration? I think the answer should be yes.