This guide outlines everything you need to know to start working with 18F's Micro-purchase team as a government employee.
18F's Micro-purchase platform enables government employees to solicit small, measurable contributions to open source software projects through the use of reverse-auctions. The opening bid for those auctions starts at $3,500 or less. During (and sometimes before) the auction period (which generally lasts one or two days), members of the public ("vendors”) can inspect the code associated with the auction in order to estimate the work and risk involved in making their contributions. Vendors place their bids accordingly, and when the auction ends the vendor with the lowest bid is awarded the contract. Delivery usually occurs within five business days after the auction closes.
That's the process in a nutshell. If you're interested in listing an auction on 18F's Micro-purchase platform, there are some additional things you should know:
Now that you have an overview of 18F's Micro-purchase Platform, let's see how Micro-purchases are different from regular procurements.
18F's Micro-purchase Platform requires that agencies and vendors collaborate in the open using GitHub. While this is standard practice in the open source community, it's often entirely new to many of the agencies with whom we work. Collaborating in the open may require that you — and, perhaps, your office or agency — think critically about how you will manage and solicit contributions to open source software projects, as well as how you'll interact with vendors and members of your team in view of the public. As mentioned throughout this guide, we're happy to help with this, as this is central to how 18F works.
Additionally, soliciting contributions from members of the public will require that you maintain documentation surrounding your project, specifically around how members of the public can download your code, run it on their local machines, and make contributions. If your project is sufficiently complex, you (and your team) will also need to maintain an automated test suite to ensure that contributions don't break the software's existing functionality. Our team is happy to work with you and your agency in creating and maintaining documentation, and, if necessary, in p mentioned twriting your initial test suite.
The final difference promoted by 18F's Micro-purchase Platform is in the nature of the source code to which vendors are being asked to contribute. Open source dramatically changes the procurement dynamic. Whereas traditional software procurements often ask vendors to submit proposals based on incomplete information, procurements centered around open source software projects give vendors full access to the software they're being asked to modify before they submit their proposals. This allows vendors to download, test, and run the code on their own machines, which in turn helps them to provide much better estimates of the work that will be involved in making the changes you've requested.
While contributions purchased through 18F's Micro-purchase platform have the capacity to do any number of things, there are some things to keep in mind as you plan your requests, namely: 18F's Micro-purchase Platform is not a replacement for staffing a dedicated product team that uses industry-proven best practices such as agile development and user-centered design. By way of analogy, Micro-purchases are useful for moving your ship forward, not steering your ship. We see them as a complement to the entire range of products and services that 18F has to offer.
In short, there are three steps you'll need to follow before you're ready to create your first auction. In this section we'll cover how to prepare yourself (and your team) to manage an open source project, how to get started with GitHub, and how to sign an interagency agreement (IAA) with 18F.
Before you can reasonably ask members of the public to make contributions to an open source software project, there are a number of considerations that you'll need to make. The first thing you'll want to do, if necessary, is to make the case for open source software within your office or agency. To that end, you might reference Play 13 ("Default to Open”) in The United States Digital Services' Playbook; the White House's recently published Federal Source Code policy, which mandates that at least 20% of new, custom-developed software be open source code; and 18F's own open source policy. At the very least, you'll need to ensure it's okay for your office or agency to create or contribute to a publicly visible open source software project.
Next, you'll want to ensure that you're thinking like a product manager. To that end, we recommend reading the following guides and articles:
Each of these guides and articles helps break down the culture of collaboration — the culture that ultimately drives successful open source software communities — into a set of actionable steps and considerations. The last article, in particular, has a particularly insightful quote as to why the open source project Ansible has been so successful:
One of the things that allowed Ansible to spread very quickly was that both the product and the documentation were optimized for the quickest possible successful first experience. An easy install experience and a friendly introduction in the documentation help to create a "shallow end” to the pool where new users can wade in, without having to dive into the deep end head first. The idea that a user can try something out over a lunch break, and understand it—and then learn what is left to learn—is a key success driver for open source software. Too many projects fail needlessly because they don't invest in this critical idea.
Next we'll briefly cover how to get started with GitHub. This section covers creating a GitHub account, creating or locating the repository on GitHub that will store public contributions, and preparing your repository for those contributions.
To create a GitHub account associated with your agency, start by visiting apps.gov to see if your agency has already procured a license for GitHub. If your agency has, contact your IT administrator for more information on how to make use of that license. If your agency has not, go ahead and create an individual account on the GitHub website using your agency-related email address.
The next thing you'll want to do is to create a GitHub repository to host the content and code associated with your new project. See GitHub's documentation and 18F's Open Source Guide for more information. By the end of this step you should have (or be able to identify):
The GitHub account you'll use to correspond and collaborate with 18F, Micro-purchase vendors, and members of the public.
One or more GitHub repositories for which you want to solicit contributions.
In each of your GitHub repositories, you'll need:
README.mdfile, explaining the purpose of the project and how members of the public can download and run a copy locally. Remember, an easy install experience and a friendly introduction in the documentation will help to create a "shallow end” for new users to wade in.
CONTRIBUTING.mdfile, explaining the process for contributing to the project and resolving conflicts.
LICENSE.mdfile, contaning the conditions under which this project may be used, modified, or shared. This should be some variant of CC0.
Next you'll need to formalize your office or agency's relationship with 18F so we can work more closely together. If you aren't part of an already existing interagency agreement (IAA), please read our primer on interagency agreements and reach out to email@example.com. We'll take it from there.
By now you're at least somewhat familiar with 18F's Micro-purchase Platform, open source software, the tenets of product management, and the basics of GitHub. You've signed an interagency agreement with 18F. Now head on over to our guide to creating your first auction.