In-house development. This phrase can often give developers a sense of freedom while also causing panic. Sure, there’s the basic activities of requirements gathering, development, testing, and deployment, no matter what development process or technology you plan to use. But, beyond that, then what? With the time crunch to get an app built, many government staff do not have the luxury to plan out further details like “community” management or legal issues they could encounter with their in-house projects.
Fortunately, a lot of the hard work has already been done for government staff in terms of best practices for developing in-house open source projects. The Civic Commons Wiki covers many of these topics and even provides easy to follow checklists, some of which are listed below.
Avoiding Technical Debt – Technical debt, as explained by Ward Cunningham, is that pain incurred in a software project near the end when, although all the features are fleshed out and operational, the development was done in such haste that the project is largely disorganized. Disorganization later is more expensive then a little organization upfront. That’s the “interest” you’ve paid on your technical debt. For a checklist of items to put into place for a government open source project before and during development, checkout the Civic Commons’ Legal Guide section on Guidelines for Open Source Development Infrastructure.
Contributions to Code from Outsiders – One of the benefits of open source development is the ability to leverage volunteer programmers from outside your team to contribute to the code base and desired features. However, management of these volunteer resources add an extra burden and potentially additional liability. What are some of the best practices around managing outside code contributions? Read more in the Community Contributions to Code section of the Legal Guide.
Data Standards and Data Use – Many times the in-house developed projects will be using data or data standards for the first time, and now offering that data to the public, potentially triggering legal issues. For example, in a guide written by the Department of Defense on Open Technology Development, a suggested best practice is to evaluate any data standards in use by an application to ensure that any licensing requirements for intellectual property protected data standards are met. Further, the Civic Commons Wiki has a page on data standards in use in various government organizations. Read more in the Data Standards/Data Use section of the Legal Guide.
Defamation Issues from Content – While legal issues with content served by in-house open source applications usually focus on data privacy issues, as well, the potential for defamation from content needs to be examined, especially with content management systems, which mainly serve employee generated content. In an article by the International Municipal Lawyers Association, the attorneys authoring the piece cover trending legal issues with social media which is largely content based. Further, the article covers the categories in which most content based lawsuits fall, one of these categories being “defamation.” Read more in the Content Legal Issues subsection of the Legal Guide.
In-house development can seem daunting, but when done right, and following best practices studied and experienced by fellow government staff, and shared in the Civic Commons Wiki, it can lead to first class code that is fairly immune from legal issues. The better your in-house project is designed and protected, the more likely another government entity or a support vendor will adopt it and support it, and the cheaper that support contracts will need to be since potential liabilities will be mitigated.
If you have an in-house open source development legal issue you would like to share with Civic Commons, please send us a message at discuss [at] civiccommons.org.
Photo Credit: NathanaelB Flickr Stream
