18F/micropurchase

View on GitHub
app/views/pages/docs/getting_started.html.erb

Summary

Maintainability
Test Coverage
<div class="usa-grid docs">
  <h1>Getting Started with 18F Micro-purchase</h1>

  <p class="usa-font-lead">This guide outlines everything you need to know to
  start working with 18F's Micro-purchase team as a government employee.</p>

  <h2>Overview</h2>

  <p>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.</p>

  <p>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:</p>

  <ul>
    <li>18F's Micro-purchase Platform is best used by agency leaders, product
    owners, and/or product managers (collectively referred to as "customers” of
    18F Micro-purchase) to solicit input, to help shape still-nascent ideas, and
    to increase the throughput of existing open source software projects.</li>
    <li>Outside of the Micro-purchase Platform itself, customers, vendors, and
    members of 18F generally collaborate on <a
      href="https://github.com">GitHub</a>. Github is a social coding website
    that allows us to <a
      href="https://github.com/18F/open-source-policy/blob/master/policy.md">work
      in the open</a> with our teammates and members of the public.
    Micro-purchase customers are required to setup a GitHub account. (More on
    this, below.)</li>
    <li>18F's Micro-purchase team works with customers to define projects (also
    called "scoping”); to determine the basis upon which measurable
    contributions might be made to projects (also called creating "acceptance
    criteria”); to draft, publish, advertise, and run auctions; to answer any
    questions that vendors might raise; and to ultimately sign off on vendor
    contributions. To cover the costs associated with these activities, we
    presently charge a flat fee of $1,000 for each auction we run; however, that
    fee is waived for offices within GSA's Technology Transformation Service
    (TTS).</li>
    <li>If you're not currently working with our office in a formal capacity,
    you will need to <a href="https://pages.18f.gov/iaa-forms/primer.html">enter
      into an interagency agreement</a>, or IAA, with 18F. This process can take
    up to 60 days.</li>
    <li>Running an auction requires a funding source, and the Micro-purchase
    Platform is explicitly designed to make use of an office or agency's
    purchase card (p-card). Customers can use their office or agency's purchase
    card, but they can also opt to use 18F's; we'll simply pass any
    auction-related expenses onto the funding source specified in the agreement
    between our agencies.</li>
    <li>Finally, Micro-purchases aren't intended to replace larger digital
    procurements. To date, they've <a
      href="http://micropurchase.18f.gov/insights">proven</a> most useful for
    buying small bits of content and code. In addition to their use of the
    platform, Micro-purchase customers are also expected to execute on the plays
    outlined in <a href="https://pages.18f.gov/partnership-playbook/">18F's
      Partnership Playbook</a>.</li>
  </ul>

  <p>Now that you have an overview of 18F's Micro-purchase Platform, let's see
  how Micro-purchases are different from regular procurements.</p>

  <h2>The Micro-purchase difference</h2>

  <p>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.</p>

  <p>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.</p>

  <p>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.</p>

  <h3>What Micro-purchase is not</h3>

  <p>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.</p>

  <h2>Getting started</h2>

  <p>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. </p>

  <p>Once you've read these sections, head on over to <%= link_to 'our guide to
  creating an auction', page_path('docs/creating_an_auction')%>. If you're
  feeling lost at any point in the process, just <a
    href="mailto:micropurchase@gsa.gov">send us an email</a>.</p>

  <h3>Prepare yourself (and your team)</h3>
  <p>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 <a href="https://playbook.cio.gov/#play13">Play 13
    ("Default to Open”)</a> in The United States Digital Services' Playbook; the
  White House's recently published <a href="https://sourcecode.cio.gov/">Federal
    Source Code policy</a>, which mandates that <a
    href="https://sourcecode.cio.gov/OSS/">at least 20% of new, custom-developed
    software</a> be open source code; and <a
    href="https://github.com/18F/open-source-policy/blob/master/policy.md">18F's
    own open source policy</a>. 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. </p>
  <p>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:</p>

  <ul>
    <li><a href="https://pages.18f.gov/partnership-playbook/">18F's Partnership Playbook</a></li>
    <li><a href="https://pages.18f.gov/lean-product-design/">18F's Lean Product Design Guide</a></li>
    <li><a href="https://pages.18f.gov/open-source-guide/">18F's Open Source Guide</a></li>
    <li><a href="https://changelog.com/top-ten-reasons-why-i-wont-use-your-open-source-project/">Top 10 reasons Why I won't Use Your Open Source Project</a></li>
    <li><a href="http://knightlab.northwestern.edu/2013/07/24/six-lessons-on-success-and-failure-for-open-source-software/">Six Lessons on Success and Failure for Open Source Software</a></li>
  </ul>
  <p>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:</p>

  <blockquote>
    <p>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.</p>
  </blockquote>

  <h3>Get started with GitHub</h3>

  <p>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. </p>

  <p>To create a GitHub account associated with your agency, start by <a
    href="https://apps.gov/products/github/">visiting apps.gov</a> 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 <a href="https://github.com/join">create
    an individual account on the GitHub website</a> using your agency-related email
  address. </p>
  <p>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. <a
    href="https://help.github.com/articles/creating-a-new-repository/">See GitHub's
    documentation</a> and <a href="https://pages.18f.gov/open-source-guide/">18F's
    Open Source Guide</a> for more information. By the end of this step you should
  have (or be able to identify):</p>

  <p>The GitHub account you'll use to correspond and collaborate with 18F,
  Micro-purchase vendors, and members of the public.</p>

  <p>One or more GitHub repositories for which you want to solicit contributions.</p>

  <p>In each of your GitHub repositories, you'll need:</p>

  <ul>
    <li><strong>A <code>README.md</code> file,</strong> 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.</li>
    <li><strong>A <code>CONTRIBUTING.md</code> file,</strong> explaining the
    process for contributing to the project and resolving conflicts.</li>
    <li><strong>A <code>LICENSE.md</code> file,</strong> contaning the
    conditions under which this project may be used, modified, or shared. This
    should be some variant of <a
      href="https://github.com/18F/open-source-policy/blob/master/LICENSE.md">CC0</a>.</li>
  </ul>

  <h3>Sign an IAA with 18F</h3>

  <p>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 <a
    href="https://pages.18f.gov/iaa-forms/primer.html">read our primer on
    interagency agreements</a> and reach out to <%= mail_to 'micropurchase@gsa.gov',
      'micropurchase@gsa.gov' %>. We'll take it from there.</p>

  <h3>Create your first auction</h3>

  <p>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 <%= link_to 'creating your first auction',
    page_path('docs/creating_an_auction') %>.</p>
</div>