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

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