One Hat, Two Hats How to Handle Open Source and Work ! Ken Walker @kwalker What prompted this talk? My last job was so secretive… easy… § IBM’s J9 JVM Lead for Embedded and Mobile platforms § Phones were secret § Car in-dash systems were secret § Black Game Consoles with Blu-ray… secret § Blog posts? Not so much to talk about ! § Open Source? In the later stages yes, but not for 10 years Along came Orion! § IBM Eclipse Developers working on new Web platform § Initial Eclipse contribution January 2011 § I joined the team in the Fall of 2011 § My goal was to grow the team, the community and IBM adoption § Orion didn’t match IBMs standard Eclipse process § Adopted a more aggressive release cycle of 3 times per year Everything was going smoothly § Why? We didn’t really have any key IBM adopters thru 2012 ! § Some teams were utilizing the Orion stand-alone editor component § That gave the developers free reign, open source deployments only to OrionHub § Team still split between Eclipse and Orion duties § But progress was being made 2013 - Things started to change § Hacked together integration demos earlier in 2012 changed some minds § Add the reality that IBM teams eager to push tooling to the web § Starting in February IBM wanted a complete solution by a June IBM Conference § Early beta of IBM JazzHub (now IBM DevOps Services) delivered § Other IBM teams on-boarding even including Rational web tools for Cobol § Other Open Source contributors SAP, HP and Pivotal getting involved § The IBM Orion team started growing to meet demand The CDD Phase - or Conference Driven Development § The start of the dark times… where feelings of “conflict” would start § These IBM Conferences did not necessarily align with Orion deadlines ! Pulse Impact Innovate ! 2013 Innovate Impact BlueMix GA 2014 2015 ! ! Orion 2.0 Orion 3.0 Orion 4.0 Orion 5.0 Orion 6.0 Orion 7.0 ! § Conflicts both ways (late changes to Orion release, or late cycle IBM content) § Requirements that can push the project in a particular direction § Through late 2013 and early 2014 list really started to impact us § And this was just one of our product engagements… Tight Deadlines and the consequences § Mocking of internal teams ;-) “What, you’re just shipping product?” § Internal “Orion” calls, or hijacking external calls § Internal “UX/UI” reviews of common components § Lack of evangelism for Orion proper • few blog posts/videos for OS but more for product § Not paying proper attention to mailing list or patch requests § Completely missing or downplaying Orion milestones “When’s M1?” “That was two weeks ago…” Features, Form and Function § How to differentiate platform from Product (give away the farm) § Sometimes it’s about asking for forgiveness (push to open source) § PaaS integration with CloudFoundry § npm module for Node debugging in PaaS environments § Stronger integration with GitHub (competition but ubiquitous) § Leverage IBM Globalization testing/translation for Open Source § Sometimes it’s about product (keep internally) § Jazz SCM integration, or features that are not OS based § UI Customizations that match L&F of Product (beware of the Dali clock) § Overall the extensibility requirements for IBM benefit community adoption What about others working in Open Source? Michael Brooks - Adobe Software Barista § Previously worked for Nitobi (acquired by Adobe) § Developer for both PhoneGap Enterprise (closed source) and Cordova (OS) § PhoneGap donated to Apache Cordova § wanted to preserve copyrights pre-Adobe Mentality is contribute early, ask forgiveness @mwbrooks § Spends mornings working on community posts, forums, questions, rest of day on code § Evenings on side projects, or side projects in side projects § Believes credibility of Product goes a long way if you get the actual developers speaking vs. marketing advocates Gorkem Ercan - Red Hat Software § Works on Cordova and tooling for Cordova development § Current tooling project is Eclipse THyM § Finds little conflict as projects are from the ground up vs. top down - work on new important projects to include later § One main issue with OS projects is internal communications § Code gets released and you hear “we discussed this” @GorkemErcan § Finding Release Labels for projects becoming meaningless, stable features are what is important § With an OS Company, there is risk a component could be abandoned § The importance then is to develop community around it § When previously working at Nokia he found OS a second thought, product came first Ian Bull - EclipseSource § Works on tooling/training based on Eclipse for profit § “Code is Crap” - costs a lot of money to write, more to maintain § If you’re going to write a component/module, then consider open source and build a community around it § Believes modularity improves if you take individual components apart and create a project (less reaching) @irbull § If your company depends on an OS component you better consider investing because other supporters may drop § Being open leads to credibility on product side § When they give talks they are known as experts in the field § Tried once to fund development of a patch for Eclipse, failed completely. Donating the patch actually improved it § Measuring success related to OS can be hard Chris Aniszczyk - Head of Open Source @twitter § Works on the OS that Twitter runs on § Engineers are stretched thin both in OS and Product § Two groups, one 90% time on product, other 90% time on OS § Product teams still try to push change to OS for their needs § Product tends to lag behind OS development (they need stable releases) @cra § Introduced Hack Weeks to catch product up to latest releases § Need to have OS contributors working with external adopters § Features grown that internal teams didn’t know they needed § Twitter needs this outside voice to lend credibly to the OS work § Have abandoned projects due to shift from Ruby to JVM/Scala § Finds OS work still needs justification and metrics for success Lessons learned - possible ways to survive § Delivery - changed to weekly sprints both in Open Source and Development § Set a schedule for OS evangelism distributed among team § Instead of big bang New & Noteworthy, publish when sprint contains new feature § Push for responsiveness to mailing lists, patch requests § Don’t hijack the calls, be more cognizant about posting change/ideas on lists/wiki § @cra - Introduce Hack Weeks to catch product up to latest releases § @mwbrooks - Get developers in front of other developers § @kwalker/@mwbrooks - Contribute to OS early, ask forgiveness § @irbull - Contribute your small libraries to OS. Let others improve on them § @irbull - If your product depends on OS components, you’d better consider contributing § @GorkemErcan - Don’t focus too much on internal communications - be open § @irbull/@cra - Metrics for success of OS related to Product, can be difficult Q&A ! What about you? Ken Walker @kwalker