One Hat, Two Hats How to Handle Open Source and Work

One Hat, Two Hats
How to Handle
Open Source
and Work
Ken Walker
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
Impact Innovate
BlueMix GA
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
§ 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”
§ Finding Release Labels for projects becoming meaningless,
stable features are what is important
§ With an OS Company, there is risk a component could be
§ 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)
§ 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
§ 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
about you?
Ken Walker