Inner Sauce at Just Eat

Explore how a global engineering team avoid duplication, encourage collaboration, and focus on single solutions. Just Eat explain how they apply open source practices internally.

Transcript

1. Inner Sauce Elliot Blackburn, Software Engineer
2. Hey! Elliot Blackburn, Software Engineer at JUST EAT @elliotblackburn bluehatbrit www.elliotblackburn.com </>
3. Engineering at Just Eat
4. Global Engineering Approx 800 engineers spread across 3 continents
5. Over 90 engineering teams
6. Over 850 components
7. Open source and inner source
8. Open Source?
9. Offering the code alongside your software.
10. The benefits
11. 1. Don’t reinvent the wheel
12. 1. Don’t reinvent the wheel 2. No need to be a domain expert
13. 1. Don’t reinvent the wheel 2. No need to be a domain expert 3. More eyes to find bugs and security issues
14. 1. Don’t reinvent the wheel 2. No need to be a domain expert 3. More eyes to find bugs and security issues 4. Don’t like something it? “Fork” it.
15. The principles
16. Open source is transparency
17. Open source is participation
18. Open source is collaboration
19. The Ruby way Core team of trusted individuals Core team have commit access to repo Matz leads direction, doesn’t review everything High interaction from the outer community.
20. The Linux way Individual module leads, trusted individuals Module lead is the gateway for that module Module leads submit bulk changes to Linus Linus’s repo is the “core” repository, many forks exist
21. Inner Source?
22. “Using open source principles and practices internally within an organisation”- Me
23. What isn’t Inner Source?
24. Inner source is not open sourcing everything
25. Inner source is not getting bug fixes for free
26. Inner source is not bikeshedding every change
27. Inner source is not discussing everything with everyone
28. Inner source is not forcing everyone to use git
29. Just Eat’s Inner Sauce
30. Our culture
31. Open by default
32. Reaching out beyond your team
33. Learn from experts in other topic areas
34. Impact the entire org rather than just your team
35. Great for personal development
36. The practicalities
38. Open repositories
39. Make it easy to submit changes
40. Good docs vs Bad docs
41. The release process
42. 1. Publish 2. Document 3. Blog 4. Speak
43. Common issues
44. Sole maintainer leaves AWSudo - Interacts with our AWS identity service for Mac/Linux users Small project, with one maintainer
45. Just fork it!
46. “Who owns XYZ?” Running services need a team to be on call Code still treated as inner source Quality of changes must be higher Be nice, tell someone before you start using their service in prod.
47. Adding some Inner Sauce to your org
48. 1. Open up your code
49. 2. Start small 1. Open up your code
50. 3. Write great docs 2. Start small 1. Open up your code
51. 3. Write great docs 2. Start small 1. Open up your code 4. Talk about your work
52. @elliotblackburn bluehatbrit You made it!