kidwellj/findcommonground.uk
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

more typos

Browse source
This commit is contained in:
Holger Reinhardt 2016-08-24 23:22:16 +02:00
parent d0a5d3fee1
commit c04f12820f
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
_posts/2016-08-24-summary-paypal-innersource.md
View file

@ -12,9 +12,9 @@ header-img: "images/bg-post.jpg"
From April 21st to 22nd, 2016 we were fortunate to attend the [PayPal Inner Source Summit](http://paypal.github.io/InnerSourceCommons/events/) in London.
We first got exposed to the InnerSource concept through a talk by PayPal at the [OSCON 2015](https://hlgr360.wordpress.com/2015/11/04/notes-from-oscon-europe-2015/) in Amsterdam in fall of 2015. At that point we were struggling to resolve a multitude of project dependencies on our backend platform team, which is now called Foundational Services. The modus operandi of the team was highly interrupt driven, reactive and managed largely through tickets raised by other teams looking for changes or additions to existing services. There was precious little time which the team could proactively invest into reducing technical debt or improving operational efficiency. Needless to say the foundation of the so called 'Haufe Group Service Platform' (HGSP) continued to deteriorate. (The HGSP was also the topic of [my recent talk on the Automated Monolith](http://www.apiacademy.co/resources/api360-microservices-summit-the-automated-monolith/) at the API360 Microservice conference in New York).
We first got exposed to the InnerSource concept through a talk by PayPal at the [OSCON 2015](https://hlgr360.wordpress.com/2015/11/04/notes-from-oscon-europe-2015/) in Amsterdam in fall of 2015. At that point we were struggling to resolve a multitude of project dependencies on our backend platform team. The modus operandi of the team was highly interrupt driven, reactive and managed largely through tickets raised by other teams looking for changes or additions to existing services. There was precious little time in which the team could proactively reduce technical debt or improve operational efficiency. Needless to say the foundation of the so called 'Haufe Group Service Platform' (HGSP) continued to deteriorate. (The HGSP was also the topic of [my recent talk on the Automated Monolith](http://www.apiacademy.co/resources/api360-microservices-summit-the-automated-monolith/) at the API360 Microservice conference in New York).
Before I dive more into the topic, let me first summarize what InnerSource stands for: To apply the concepts of Open Source to the closed internal software inside of your company. You can read more about it at the [InnerSource Commons](http://paypal.github.io/InnerSourceCommons/) and/or download a free copy of the [InnerSource eBook](http://www.oreilly.com/programming/free/getting-started-with-innersource.csp). If you google it you will also find some articles, for instance [here](http://thenewstack.io/github-bloomberg-talk-using-innersource-build-open-source-project-development-behind-company-firewalls/) and [here](https://www.infoq.com/news/2015/10/innersource-at-paypal).
Before I dive more into the topic, let me first summarize what InnerSource stands for: To apply the concepts of Open Source to the internal software development inside of your company. You can read more about it at the [InnerSource Commons](http://paypal.github.io/InnerSourceCommons/) and/or download a free copy of the [InnerSource eBook](http://www.oreilly.com/programming/free/getting-started-with-innersource.csp). If you google it you will also find some articles, for instance [here](http://thenewstack.io/github-bloomberg-talk-using-innersource-build-open-source-project-development-behind-company-firewalls/) and [here](https://www.infoq.com/news/2015/10/innersource-at-paypal).
What made us excited about the InnerSource concept was the premise to unwind or at least greatly reduce those external dependencies, and thereby freeing up the core team to focus on evolving the platform itself. It does so by offering dependent projects the ability to add their required enhancements to the platform code base vs. having to wait for the platform team do it for them.
@ -26,7 +26,7 @@ To me there are two macro patterns at work here, which seem to point into the sa
* Change the perspective from a point solution (add more developer) to changing the motivators in the system (enable external teams to take care of itself). The same can be said about the [Netflix approach of 'Chaos Engineering'](http://readwrite.com/2014/09/17/netflix-chaos-engineering-for-everyone/). Instead of pretending that QA can catch every bug (and thereby contributing to an illusion of bug-free systems), Netflix deliberatly introduces failure into the system to force engineers to design software anticipating the presence of failure.
* Efficiency and Speed are goals at opposite ends (I owe that insight to the folks from Thoughtworks). You can not have both of them at the same time. Microservices (MSA) embrace speed over efficiency through its emphasize on a `shared nothing` approach. In effect MSA is saying that databases and app servers are commodity by now and that you do not gain significant business value by using them efficiently. MSA emphasizes duplication and the reduction of cross dependencies over having a central instance which will become the bottleneck.
Las but not least I would like to thank Danese Cooper and her team for so openly sharing their lessons and knowledge.
I would like to thank Danese Cooper and her team for so openly sharing their lessons and knowledge.
Here are my notes from the various sessions under the [Chatham House Rule](https://www.chathamhouse.org/about/chatham-house-rule).
@ -177,4 +177,4 @@ On a side note: For me personally it was eye opening to discuss the implications
* because being the owner means `if it breaks it is on me` and therefor I will do everything in my power to limit my risk
* which counteracts agility and controlled risk taking
The key here seems to be an institutional bias on 'if it breaks'. If the default assumption is that it can go wrong, it is clear that we would prefer to have one person responsible. But obviously embracing the possibility of (controlled) failure is what makes all the difference in execution speed between a startup and an enterprise, between a 'fail fast' and a risk avoidance culture. But this is a topic worth of a separate blog post.
The key here seems to be an institutional bias on 'if it breaks'. If the default assumption is that it can go wrong, it is clear that we would prefer to have one person responsible. But obviously embracing the possibility of (controlled) failure is what makes all the difference in execution speed between a startup and an enterprise, between a 'fail fast' and a risk avoidance culture. But this is a topic worthy of a separate blog post.