$30 off During Our Annual Pro Sale. View Details »



Alain Hélaïli

January 29, 2018

More Decks by Alain Hélaïli

Other Decks in Technology


  1. Opensource Alain Hélaïli a @helaili - @AlainHelaili

  2. • Richard Stallman • 1983 • GNU’s Not Unix •

    Make, Emacs, GCC, GDB • GNU Public License • vi vi vi is the editor of the beast
  3. 1985 1999 2000 2003 2004 2008

  4. None
  5. None
  6. None
  7. Not only code • Creative Commons - 2001 • Wikipedia

    - 2001 • Massive Open Online Courses - 2006 • Open data • Open government • 3D print files
  8. Linux is a cancer Q: DO YOU VIEW LINUX AND

  9. Microsoft Joins the Linux Foundation

  10. The cathedral and the bazaar • First essay in 1997

    • Published in 1999 under Open Publication License • Linus’ law: “given enough eyeballs, all bugs are shallow”
  11. The cathedral and the bazaar • Every good work of

    software starts by scratching a developer's personal itch. • Good programmers know what to write. Great ones know what to rewrite (and reuse). • Plan to throw one [version] away; you will, anyhow. (Copied from Frederick Brooks' The Mythical Man-Month) • If you have the right attitude, interesting problems will find you. • When you lose interest in a program, your last duty to it is to hand it off to a competent successor. • Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  12. The cathedral and the bazaar • Release early. Release often.

    And listen to your customers. • Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. • Smart data structures and dumb code works a lot better than the other way around. • If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. • The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  13. The cathedral and the bazaar • Often, the most striking

    and innovative solutions come from realizing that your concept of the problem was wrong. • Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry) • Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. • When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  14. The cathedral and the bazaar • When your language is

    nowhere near Turing-complete, syntactic sugar can be your friend. • A security system is only as secure as its secret. Beware of pseudo-secrets. • To solve an interesting problem, start by finding a problem that is interesting to you. • Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
  15. Pure players

  16. OSS != Free • Open core • Freemium • Embed

    • Certification • Modification • Liability • Support • Ecosystem
  17. Notables

  18. None
  19. None
  20. None
  21. Unexpected

  22. None
  23. Even more unexpected Fostering an Open Source ecosystem in Financial

  24. What could possibly go wrong?

  25. "

  26. None
  27. None
  28. None
  29. Why YOU should open source

  30. Why YOU should open source

  31. Opensource strategies • Consume open source software • Contribute back

    to the projects you use • Release new open source projects • Embrace opensource as a strategy
  32. Why open sourcing code • Great advertising for you and

    your company… translat[ing] into goodwill for [your company] and more superfans than ever before • Attract outside contributions : create a force multiplier that helps you get more work done faster and cheaper. More users means more use cases being explored which means more robust code
  33. Why open sourcing code • Attract talent : Smart people

    like to hang out with other smart people. Smart developers like to hang out with smart code. • Best technical interview possible, the one you don’t have to do because the candidate is already kicking • Retain talents • Favor quality
  34. Innersource • Open inside only • A foot in the

    door for open source • Improve reuse • Improve cross-team collaboration • Cultural change agent
  35. Contribution strategies • Let developer contribute back their changes •

    Give time to actively contribute beyond immediate needs • Opensource homegrown projects
  36. Considerations • Opensource repo vs ftp server • The role

    of the community • Project lifespan • Legal framework for employees • Intellectual property - Balanced Employee IP Agreement • Passion vs extra-hours
  37. Build a community

  38. None
  39. Opensource guides • Open Government Partnership collaboration : https://github.com/DISIC/foss-contrib-policy-template •

    USA 18F : https://github.com/18F/open-source-policy/blob/master/CONTRIBUTING.md • Whitehouse source code policy : https://sourcecode.cio.gov • UK GDS : http://gds-operations.github.io/guidelines/ • Canada British Columbia : https://github.com/bcgov/BC-Policy-Framework-For-GitHub • Linux Foundation open-source guides : https://www.linuxfoundation.org/resources/open-source-guides/ • Core Infrastructure Initiative : https://bestpractices.coreinfrastructure.org/ • Open-Source Guide : https://opensource.guide/ • FSFE software reuse : https://reuse.software/ • Google open-source : http://opensource.google.com • Canada : https://github.com/canada-ca/Open_First_Whitepaper • France : https://disic.github.io/politique-de-contribution-open-source/
  40. None