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 

Agile Web Development Liip.ch – DISCLAIMER: I AM NOT AN ACTIVE PARTICIPANT OF THE TYPO3 COMMUNITY I AM TALKING TO YOU AS AN OUTSIDER 

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 

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? 

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 

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/ 

SPIRIT OF OPEN SOURCE 

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 

DOCUMENTATION • Documenting code • Components need standalone docs • Frameworks need docs showing the flow between the components • Documenting processes 

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? 

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) 

LET US FIND THE URL TO THE CODE REPOSITORIES ON TYPO3.ORG AND NEOS.IO 

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) 

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 

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?!? 

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. 

ECONOMIES OF SCALE VS. PERFECTION(ISM) 

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 • .. 

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 

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 

Agile Web Development Liip.ch – WHAT ELSE DO YOU THINK IS IMPORTANT THAT I FORGOT TO MENTION? 

Agile Web Development Liip.ch Lukas Kahwe Smith [email protected] @lsmith THANK YOU VERY MUCH FOR YOUR ATTENTION!