Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Playing well with others

lsmith
July 18, 2015

Playing well with others

Open source is of course about much more than just having the source open. Its also very much about community and collaboration. These things are much harder to plan than hard facts like algorithms. What is worse is that community and collaboration require a lot of effort before they start to bring practical benefits. But community and collaboration can clearly have a tremendous effect on the success of open source projects. The aim of this talk is to discuss what it takes to enable community and collaboration. What are maybe even painful aspects that one needs to be willing to accept. But also what immediate and direct benefits can also be gained.

Talk given at T3DD15: https://t3dd15.typo3.org/schedule/sessions/2414faa5-1d2c-44d7-8050-1310e67fd5a1

lsmith

July 18, 2015
Tweet

More Decks by lsmith

Other Decks in Programming

Transcript

  1. Agile Web Development Liip.ch Lukas Kahwe Smith [email protected] @lsmith PLAYING

    WELL WITH OTHERS Or considerations to make your project a good open source citizen
  2. Agile Web Development Liip.ch – DISCLAIMER: I AM NOT AN

    ACTIVE PARTICIPANT OF THE TYPO3 COMMUNITY I AM TALKING TO YOU AS AN OUTSIDER
  3. Agile Web Development Liip.ch – I SERVED AS CO-RELEASE-MANAGER FOR

    PHP 5.3, WHICH TAUGHT ME A LOT ABOUT OSS ORGANIZATION I ALSO HAVE MY FINGERS INTO DOZENS PHP PROJECTS AND HAVE BEEN EARLY ADVOCATE OF MANY MORE
  4. Agile Web Development Liip.ch – WHAT IS THE ULTIMATE GOAL?

    PROVIDING AS MUCH UTILITY AS POSSIBLE TO THE PROJECT MEMBERS? MAKING THE WORLD A BETTER PLACE? HAVING FUN?
  5. LEGAL QUESTIONS • License • (L)GPL: require sharing modifications •

    MIT/Apache: allows commercial use • BSD: allows proprietary forks • Further agreements • CLA: project has full control over copyright, i.e. sign before contribution • FLA: project can defend copyright, i.e. sign a er contribution
  6. OPEN SOURCE != OPEN SOURCE SOFTWARE • Open code, doesn’t

    mean you follow the spirit of open source • In other words source code access is just one aspect of what people associate with open source and its success • F.e. adding an open source license to proprietary code makes it open source so ware but not automatically an open source project Further reading: h p://haacked.com/archive/2012/02/16/open-source-and-open-source-so ware-are-not-the-same.aspx/
  7. MY CHECKLIST • Good open source projects have documentation to

    get started and beyond • Good open source projects make it easy to get the code • Good open source projects do not reinvent the wheel • Good open source projects make it easy to provide feedback and changes • Good open source projects integrate new developers quickly • Good open source projects know how to deal with conflicts • Good open source projects know how to deal with different background
  8. DOCUMENTATION • Documenting code • Components need standalone docs •

    Frameworks need docs showing the flow between the components • Documenting processes
  9. COMMON FRUSTRATIONS • Where to submit code (project specific infrastructure

    or github/bitbucket/..)? • What are the requirements for code contributions (RFC, CS, tests)? • How is feedback provided, who and how are decisions made? • What makes sense to work on? • When will my contributions be in a released?
  10. COMMON FRUSTRATIONS EXAMPLES • Where can I browse the repository?

    Where is the URL to the git repo? • How many clicks does it take ..? • Does TYPO3 use their own packagist/satis? • Found out its only for legacy TYPO3 extensions but it confused me • TYPO3 README.md contains useful information but links are very general • exact URL to submit tickets and to the coding style etc (ie. CONTRIBUTING.md)
  11. CLEAR PROCESSES • Without clearly documented processes only the current

    leaders know how to get their voices hear while newcomers and minorities end up frustrated • Processes can and should evolve with the needs of the project and its members • Ideally processes should be shared across projects just like code (f.e. PSR-9 and PSR-10 aim to do this for security reporting and disclosure)
  12. COMPOSER • Goal is decoupling, ie. as few dependencies as

    possible • Consider bridge packages instead of optional dependencies • Consider interface packages and using “provides” in composer.json • Think long and hard before using your own composer infrastructure
  13. COMPOSER FRUSTRATION EXAMPLE • Lets build my own TYPO3 by

    using a subset of core components • TYPO3 CMS uses “replaces” for many packages but these packages are not registered on packagist.org • Lets use TYPO3 Fluid in a different framework • “typo3/cms-fluid” requires “typo3/cms-flow” • “typo3/flow” requires “doctrine-migrations” • TYPO3 Fluid depends on Doctrine Migrations?!?
  14. SOME WORDS ON NIH SYNDROM • NIH = Not Invented

    Here, aka Reinventing The Wheel • Open source projects should focus on unique selling point • Using 3rd party dependencies bring risks and opportunities • Risks: Lifecycle management, dependencies management, complexity, etc. • Opportunities: Less work, more features, cross-pollination, encourages be er extension point design, etc.
  15. PHP COMMUNITY PARTICIPATION • Trust needs to be built, best

    way is to show your faces in various places • PHP FIG - framework interoperability group • Conferences • User groups • Twi er • ..
  16. https://twitter.com/Ocramius/status/621326699024785408 • Sarcasm is dangerous, especially on twi er •

    Do not react overly defensive • If you think a statement makes no sense, do not even engage, ie. do not feed the trolls • If necessary take discussion to direct exchange to avoid misunderstandings ge ing out of hand in public space
  17. SOME WORDS ON MERITOCRACY • Definition Meritocracy: society governed by

    people selected according to merit • Definition Merit: quality of being particularly good or worthy, especially so as to deserve praise or reward • In open source quality o en equals skill and having time to invest • Measuring merit tends to be done with a bias of the current leaders • Ensure minorities are heard, their skills are recognized see also “Talk about nothing” by Lena Reinhard h ps://www.youtube.com/watch?v=D3e3V66TH2Y
  18. Agile Web Development Liip.ch – WHAT ELSE DO YOU THINK

    IS IMPORTANT THAT I FORGOT TO MENTION?