Building Innovation with Open Source Approaches
1 like558 views
The document discusses how to build innovation using open source approaches. It outlines how the author founded WSO2 in 2005 based on three core principles: being lean, using open source software, and having a global team based in Sri Lanka. It argues that true open source companies focus on open development, community, licensing processes, and people rather than just publishing open source code. WSO2 has focused on these open source principles and practices like open development to drive innovation in their products like WSO2 Carbon and Stratos platform.
![How to build innovation using Open Source approaches Paul Fremantle [email_address] @pzfreo / Twitter CTO and Co-Founder, WSO2](https://image.slidesharecdn.com/transfersummit-fremantle-100624092756-phpapp02/85/Building-Innovation-with-Open-Source-Approaches-1-320.jpg)
Building Innovation with Open Source Approaches
- 1. How to build innovation using Open Source approaches Paul Fremantle [email_address] @pzfreo / Twitter CTO and Co-Founder, WSO2
- 2. Me Open Source Wrote my first public domain code in 1992 Posted on FidoNet First involvement with Apache in 2000 Spoke at ApacheCon London 2000 Member of the ASF, on several PMCs VP/Apache Synapse Work 9 years at IBM, leaving as a STSM in WebSphere Architecture Set up WSO2 in 2005 Named Infoworld CTO 25 in 2008 Technical team of ~60 people Home Two children 13 and 9 Play the tin whistle Occasional blacksmith
- 3. Themes for this talk Open Source / Open Development What is an Open Source company? Does Open Source promote innovation? What can companies learn from Open Source? Usability isn’t just about UIs What have we (WSO2) done that we think is innovative?
- 4. How do you encourage innovation?
- 6. A short history of WSO2 Founded in August 2005 By 3 Apache Members US, UK, Sri Lanka Three core thoughts: Lean software based on standards and interop Open Source Global company with core team in Sri Lanka
- 7. A view of Open Source companies – There are No Open Source companies Only companies that make money: • via expertise in consultancy • hoarding copyright ownership for a big sale • providing additional value on top of OSS products • licensing fear, uncertainty and doubt (choosing GPL to make users who fear GPL pay) Henri Yandell commenting on my blog: http://bit.ly/c7xOow My response: http://www.sdtimes.com/link/34351
- 9. What does is mean to be “Open Source” Publish code under an OSI approved license Have some part of your code Open Source Support Open Source software
- 12. WSO2’s differentiation is focus on all things Open Source Open Development Community License Processes People
- 13. Why the Apache License?
- 14. Usability U.S. Mission Photo: Eric Bridiers
- 15. Open Source Processes Photo http:// garth.vox.com /
- 16. Open Development
- 19. The suits are not (completely) in charge Everyone is encouraged to challenge Product managers are often younger than their team Engineers pitch in on marketing and sales issues Not all experienced hires fit into this well
- 22. eBay
- 24. WSO2 Carbon
- 26. Cloud Native
- 27. WSO2 Stratos: Platform as a Service
- 29. Summary Choose the right license …. But the license is a tiny portion of being “Open Source” Innovation is not just inventiveness The team needs to focus on real needs Try to disrupt yourself It may not work, but its certainly fun Meritocracy breeds innovation
- 30. Thank you
Editor's Notes
- #16: We let our users drive the development Shorter planning cycles than normal Balance vision with demand We do not have a separate support team Developers provide support We do have a separate QA team But developers test their systems thoroughly Hugely automated test and build We do not have a separate training/consultancy team Our customer architects contribute to the code Our developers do training and on-site consultancy We let our users drive the development Shorter planning cycles than normal Balance vision with demand We do not have a separate support team Developers provide support We do have a separate QA team But developers test their systems thoroughly Hugely automated test and build We do not have a separate training/consultancy team Our customer architects contribute to the code Our developers do training and on-site consultancy
- #17: We do everything on mailing lists Almost all our mailing lists are open Architecture Dev lists We get mails from concerned people who think there is a problem with our infrastructure Open Bug Tracker Open build processes What is closed? Customer support system Support mailing list Sales and marketing