Github

GitHub opens up about its relationship with ICE

GitHub

In a post on the GitHub blog, CEO Nat Friedman publicly addressed the company’s business relationship with U.S. Immigration & Customs Enforcement, its opinion on the current administration’s immigration policy and “the principles by which we make decisions in these areas.”

The issue is that ICE renewed its purchase of GitHub Enterprise Server for $200,000. GitHub says it will honor the contract, but will continue its advocacy against the “administration’s terrible immigration policies” and will donate $500,000 “to nonprofit organizations working to support immigrant communities targeted by the current administration.”

From the post:

Like many Hubbers, I strongly disagree with many of the current administration’s immigration policies, including the practice of separating families at the border, the Muslim travel ban, and the efforts to dismantle the DACA program that protects people brought to the U.S. as children without documentation. The leadership team shares these views. These policies run counter to our values as a company, and to our ethics as people. We have spoken out as a company against these practices, and joined with other companies in protesting them.

We respect the fact that for those of us in the United States, we live in a democratic republic in which the public elects our officials and they decide, pursuant to the rule of law, the policies the government will pursue. Tech companies, in contrast, are not elected by the public. But we have a corporate voice, and we can use our voice and our resources to seek changes in the policies that we oppose. As a matter of principle, we believe the appropriate way to advocate for our values in a democracy is to use our corporate voice, and not to unplug technology services when government customers use them to do things to which we object.

We believe that this principled approach will also be impactful as a matter of pragmatism. Attempting to cancel a purchase will not convince the current administration to alter immigration policy. Other actions, such as public advocacy, supporting lawsuits, meaningful philanthropy, and leveraging the vast resources of Microsoft will have the greatest likelihood of affecting public policy. Our voice is heard better by policymakers when we have a seat at the table.

As software becomes more important in the world, we will continue to face increasingly challenging political and social questions. Even with careful thought, we will sometimes make mistakes. My hope is that we can be an organization that works hard to make principle-based decisions, that regularly reflects on and remains willing to refine its principles, and that recognizes the inevitability of interpersonal disagreement around those principles and challenges that constructively. It’s incumbent on all of us to find ways to cohesively navigate the increasingly turbulent times we find ourselves in.

More: GitHub and US Government developers

Substantive feedback on White House open source policy as comment period extended

GitHub

The White House extended the Federal Source Code Policy comment period to April 18 and, to date, there are 147 comments with much of the discussion centered around licensing and security.

Open culture organizations, enterprise software providers, key open source advocates and federal agencies have contributed to the discussion, including Sunlight Foundation, Free Software Foundation, Mozilla, Creative Commons, GitHub, Electronic Frontier Foundation, U.S. Air Force, Department of Homeland Security, Open Source Health Record Alliance, Red Hat, Open Tech Strategies.

Favorite quote:

Requiring software to be open source by default builds a culture that supports and amplifies the benefits of open source. When it’s the default approach, developing in the open becomes second nature, rather than a separate process to follow for an arbitrary amount of projects. Measuring the amount of code released into the open as required by the 20% policy adds unnecessary overhead and burden to the process of developing open source software, and inhibits an open source-based workflow from becoming more widely adopted.

Submit your comments.

Insights from federal digital design leaders

U.S. Digital Service

Ethan Marcotte and Karen McGrane have been on a roll lately featuring federal government design leaders on their Responsive Web Design Podcast.

The first episode, with U.S. Digital Service Designer Mollie Ruskin and Lead Front End Designer Julia Elman sharing insights into their design process and prototyping tools (OmniGraffle, Sketch, GitHub) and building the U.S. Web Design Standards, has excellent insights for those focused on this aspect of the civic experience.

Favorite quote from Mollie:

“I think that one thing that you have to just come to terms with in doing a project like this is that there are so many moving pieces and it’s a lot to keep track of all at the same time, and just to sort of like take a meditative, reasoned approach to that because it can be a daunting amount. I had been given that advice before I started, and it was about halfway through that I felt the zen of all of the pieces moving and realized that that was part of the beauty of doing this work, is that by us taking on this complex important problem, we were going to be making it easier for others moving forward. So, I would just encourage a can-do attitude and plow through those times where you feel like you’re building seventeen things all at once, because you will be.”

RWD has also featured designers from Vets.gov, Consumer Financial Protection Bureau and the U.S. Department of State.

Feds publish guide to setting up an open source project

GitHub

18F has published a guide that helps federal government workers standardize GitHub use and better leverage the social coding platform when setting up open source projects.

Tips include how to best name and describe projects, create readable READMEs , write user story focused issues, wiki best practices and a GitHub repo checklist.

Additional thoughts that would make the guide more helpful:

  • Add a section on collaborators and permissions.
  • Encourage including a link for the ‘Website for this repository’ next to the description whenever possible.
  • Next to the ‘Edit this page’ link, add a ‘Submit feedback’ link to the issues section for the guide so it’s easier to giv feedback. In general, if you’re going to have either option, it’s best to have both, especially the latter.
  • One bug: The images on https://pages.18f.gov/open-source-guide/using-the-wiki aren’t responsive.

Update:

The future of government technology procurement

SideEffect.ioThe General Services Administration and 18F recently held an open request for quotation related to a new blanket purchase agreement for a federal marketplace for agile delivery services. The transparency throughout the entire process was refreshing and provides a window into the future of procurement as well as what FedBizOpps could and should be.

The RFQ asked companies to provide a working prototype with code submitted in a public GitHub repository that could be viewed, watched, forked or downloaded at any time. Timestamps built into GitHub’s commit timeline publicly exposed when a company began working and when and whether it “submitted” its final version within the allocated timeframe.

The objective of the BPA, according to 18F, was “to shift the software procurement paradigm” from a waterfall-based development model with a long, tedious approach to acquisition that typically favors large, established inside-Beltway vendors to one that encourages small business participation, and that required all companies to work in the open, using GitHub to expose not just the code, but how the teams worked together and documented their efforts.

CivicActions (full disclosure: I work for them) participated in the process, and I played a role in developing parts of the front-end and productizing the end result, which was SideEffect.io, an adverse affect comparison tool that leveraged open data from the Food and Drug Administration’s OpenFDA initiative (GitHub repo here).

Having played a minor role on the team and having an odd appreciation for how government IT leaders are working to modernize technology procurement, the process was fascinating to watch both from how GSA and 18F pushed this out and managed, but also an inside perspective on how one company responded and worked together (FCW’s Zach Noble has a great write-up on how the CivicActions team worked, the tools used and its general philosophy going into it).

My general takeaway is that this is the future of the request for information/quote/proposal process. In the future, much like what I prototyped at OpenFBO, for each procurement request, there will be repo-like tools that fully expose public input and questions, allow internal and external stakeholders to easily “watch” for updates, attach bids or quotes with an opportunity for feedback, all of which would eventually turn into the repo for developing the end product.

As GSA and 18F, and hopefully other federal, state and local agencies, continue to refine this process, whether it’s via GitHub or a Git-like platform, you can be sure this is the future of how government will procure custom-built software and services.

How and why Los Angeles deployed open source and agile

Last week at DrupalCon, representatives from the city of Los Angeles, CivicActions and Acquia shared their development and project management process to begin migrating and consolidating websites across 40 agencies to a single instance using Acquia Cloud Site Factory.

The teams shared how they moved to the open source content management system Drupal, created a responsive web design theme, developed key features and integrated other services such as video and data.

The first sites included in the consolidation plan are lacity.org and lacityview.org.

The presentation also includes a retrospective on goals achieved, areas of improvement and lessons learned. The city’s LA team adopted agile development practices and, based on the success of the project, has been asked to train other agencies.

Project management and development tools used include SMACSS, Slack, Basecamp, GitHub, Google Hangouts and Jira.

Video:

U.S. Department of Energy has a new chief data officer

Photo: U.S. Department of Energy

Photo: U.S. Department of Energy

According to a U.S. Project Open Data GitHub pull request, it appears the U.S. Department of Energy has named Dave Dutton as its chief data officer.

Dutton has officially held the title since January, and previously worked in data management related positions at Freddie Mac, McDonald’s and EDS.

From his LinkedIn profile related to his new role:

We will offer enterprise data services to eliminate silos, improve the reliability of data, and reduce security risks. We will also provide public-facing data services that are open for all consumers to use. Moreover, we will use digital and traditional mediums to deliver and receive high-value data and information in an easily discoverable, retrievable, and recordable format that promotes transparency with appropriate consumers. We will continue to strengthen our electronic and paper records management capability. All of these efforts will be supplemented by providing training and communications to the DOE workforce on the importance of records management and sharing data and information in a secure manner.

Much like new U.S. Department of Transportation Chief Data Officer Dan Morgan, Dutton has an important and enormous task of managing and making public large amounts of data and leveraging this to impact environmental, energy and sustainability changes throughout the world.

OpenFBO: re-imagining the next generation FedBizOpps

OpenFBO

Say hello to OpenFBO.

Inspired by a recent General Services Administration request for information to create a “new and improved” FedBizOpps, OpenFBO is a community experiment to re-imagine the next generation FBO.

After reading GSA’s RFI, and working with NuCivic and CivicActions on their own submissions, I began thinking about what I would do if I was in charge of FedBizOpps, leaning on what’s been done with FBOpen, OpenRFPs and particularly former Philadelphia Chief Data Officer Mark Headd’s leadership and experiments with GitHub-based procurement.

I started thinking, what if the RFI, request for proposal, the development of FedBizOpps and everything around it was more open and collaborative. What if all RFIs and RFPs were public repos where anyone could engage more in the procurement process? What are the other possibilities for making the process fair for small businesses? How can it be a more enjoyable experience for the federal workers who need to use it on a daily basis.

Inspired by Mark’s idea of GitHub-based procurement, I created a simple brand (“OpenFBO”) and website (openfbo.org) using GitHub pages, and am leveraging GitHub’s issues feature for idea submissions. There are currently two repos (one for the website and one for the first RFI).

As with any project like this, it’s also a way for me to learn more about the federal procurement process in the context of a community project. I have a lot to learn and hope OpenFBO is the mechanism for doing so. I imagine this will also open my eyes to community engagement via GitHub, which I’m really looking forward to.

To get involved with OpenFBO, connect on GitHub, Twitter, LinkedIn or subscribe to the newsletter.

So, to start things off, we’re issuing our first RFI:

How would you make FedBizOpps better?

GitChat with Gavin Newsom

Gavin Newsom

California Lieutenant Governor Gavin Newsom is our next GitChat guest. Newsom is also the author of “Citizenville: How to Take the Town Square Digital and Reinvent Government.”

For those not familiar with GitChat, it’s an open, informal chat with leading civic innovators using GitHub as a platform for engagement.

Newsom will answer questions from May 6-7 (noon-noon PT).

Submit your questions »