One
Hat,
Two
Hats
!How
to
Handle
Open
Source
and
Work
Ken
Walker
@kwalker
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
!
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
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
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 start of the
dark times
…
where feelings of “conflict” would start
§
These IBM Conferences did not necessarily align with Orion deadlines
!
!
!
!
!
§
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
…
The CDD Phase - or Conference Driven Development
2013 2014 2015
Orion 2.0 Orion 3.0 Orion 4.0 Orion 5.0 Orion 6.0 Orion 7.0 Impact Innovate Pulse Impact InnovateBlueMix GA
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?”
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)
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 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)
§ 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)
§ 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 @cra
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
