Closed source a few things

Closed source a few things

Making the case for why (just) a few things should remain closed source

19d03ecc1ff5da1a5e63a3ddaa2d84c2?s=128

Ben Balter

May 19, 2015
Tweet

Transcript

  1. ! Closed source a few things Ben Balter @benbalter government@github.com

    government.github.com
  2. ! In the beginning, there was open source…

  3. PDP-1 (or so I’m told)

  4. Open source at the Tech Model Railroad Club

  5. ! All the easy problems have already been solved

  6. ‣ How to convey material goods over large distances ‣

    How to disseminate text-based information to a large audience ‣ In computer science, just about everything up to the application layer Things people don’t worry about
  7. ! Developers should focus on solving unsolved challenges

  8. ! Unlike literature, through object code
 software allows us to

    obscure 
 from others what we’ve learned
  9. ! All alchemists had to 
 discover for themselves that

    drinking mercury would kill you
  10. ! Why closed source?

  11. ! Open source used to be hard

  12. ! Open source software used to be terrible

  13. ! Open source works behind the scenes

  14. ! Open source isn’t marketed (think suits versus t-shirts)

  15. ! Today, tech companies open source everything but the secret

    sauce
  16. Startups twitter.github.io yelp.github.io

  17. netflix.github.io adobe.github.io

  18. Tech Giants sap.github.io ibm.github.io microsoft.github.io

  19. ! Let’s say you and I want to lock our

    front door
  20. ! We each design a lock, install it in the

    door, and carry the key
  21. ! We’re also both human. Our locks are flawed

  22. ! You keep the design to yourself. After all, it’s

    a lock.
  23. ! I share my design with others, keeping the specifics

    of my key
  24. ! Neither of us are full-time locksmiths, and go about

    doing the thing we originally set out to do
  25. ! As people install my lock in different places they

    find and fix flaws. My lock gets better.
  26. ! A robber tries common ways 
 to break into

    both houses. 
 Whose stuff is more secure?
  27. ! Why open source?

  28. ! Security through obscurity versus eyes rendering all bugs shallow

  29. ‣ Your custom software being hacked doesn’t make headlines 


    (or if it does, the vendor isn’t in the story) ‣ Vulnerabilities are discovered, discussed, and patched in the open, with the fix being seen as a feature, not a potential lawsuit ‣ More rapid release cycles means more patches You hear a lot about open source vulnerabilities
  30. ! The best developers in the world versus Just the

    ones on your payroll
  31. ! Built for your (current) purpose versus Built for different

    purposes
  32. ! Proprietary standards versus Open standards

  33. ! Licensing versus Customization and support

  34. ! Why open source in government?

  35. ! Challenges not-unique to agencies

  36. ! No private-sector competition

  37. ! Day-to-day visibility into contractors’ efforts

  38. ! Attract technical talent

  39. ! Allow citizens to check your work

  40. ! Tax-payer funded code

  41. ! Don’t ask “what should be open source?”
 Ask “what

    needs to be closed source?
  42. ‣ The secret sauce — passwords, server configurations, launch codes,

    your competitive advantage, etc — where it can’t be abstracted out ‣ Anything so specific to your use case that others wouldn’t benefit ‣ Projects you don’t have the resources (or desire) to maintain — open source is free as in puppies, not free as in beer
  43. ! All organizations go through three phases of open source

  44. ‣ Consume open source — Stand up a Drupal site,

    Linux-based servers, rely on open source libraries ‣ Publish open source — Post a zip file to an FTP server 
 (or the modern equivalent) ‣ Participate in the open source community — engage developers, actively seek contributors, merge community contributions
  45. ! Open source as a platform versus Open source as

    a workflow
  46. ! Case Studies From around the Government

  47. ! Who does the government collaborate with? Within an agency

    Between agencies With the public
  48. ! Within an agency (or with external contractors)

  49. Between agencies

  50. With the Public

  51. ! What government collaborates on Open source Open data Open

    government
  52. Open source (code)

  53. None
  54. Open data

  55. None
  56. None
  57. Open government (policy)

  58. Information Sharing Environment Project Interoperability

  59. ! If you only remember two things

  60. ! 1. Open source ≠ Published source

  61. ! Open Source (software)
 software that can be freely used,

    modified, and shared (in both modified and unmodified form) by anyone
  62. ! Open Source
 a philosophy of collaboration in which working

    materials are made available online for anyone to fork, modify, discuss, and contribute to.
  63. ! 2. Optimize for developers

  64. ! You can have open source without executive oversight

  65. ! You can have open source without policy guidance

  66. ! You can’t have open source without developers

  67. ! You can’t have open source without code

  68. ! Best Practice #1: The technology is the easy part

  69. ! Open source as a vehicle for organizational change

  70. ! Best Practice #2: Start small, go through the motions

  71. ! Organizations have muscle memory

  72. ! Best Practice #3: Minimize information imbalance

  73. ! Work outside the firewall

  74. ! Best Practice #4: Minimize Friction

  75. ! Friction (n) The time it takes to go from

    
 “I want to contribute” to “I have contributed”
  76. ! Best Practice #5: Be the hub, encourage spokes

  77. ! You are the host of the internet’s most boring

    cocktail party
  78. ! Closed source a few things Ben Balter @benbalter government@github.com

    government.github.com
  79. ‣ PDP-1 — flickr.com/photos/hiddenloop/307119987/ ‣ Punch Card Decks — mehul

    panchal, via Wikimedia Commons Photo credits