Opensource

Transcript

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
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 THE OPEN- SOURCE MOVEMENT AS A THREAT TO MICROSOFT? A: YEAH. IT'S GOOD COMPETITION… LINUX IS A CANCER THAT ATTACHES ITSELF IN AN INTELLECTUAL PROPERTY SENSE TO EVERYTHING IT TOUCHES…. JUNE 1ST 2001, CHICAGO SUN TIMES
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
21. Unexpected
23. Even more unexpected Fostering an Open Source ecosystem in Financial Services
24. What could possibly go wrong?
25. "
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
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/