3 ms·

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

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 10y ago
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.

ajdlinux 10y ago

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.