The Second Step: HOWTO encourage open source work at for-profits
From Open Source Bridge wiki
Even at pro-FLOSS businesses, logistical obstacles and incentive problems get in the way of giving back. I’ll show you how to fix that.
Speaker: Sumana Harihareswara
Return to this session's details
How you should encourage open source contributions within for-profits: The Second Step
Open Source Bridge, Monday 1 June 2010
The very short version: a company does not upstream its patches, even though it should for long-term practical reasons, because of problems in four general categories. The company might lack a FLOSS culture. There might be legal confusion about what employees are allowed to do, and how to get permission. The project management workflow and timelines might not allow time for proper engineering. And the external project might have a terrible UI for new contributors.
Once you abstract these categories away from the specific problem of accidentally hoarded code rotting away, you see that they also apply to other problems of the type "I really know I should be doing foo but haven't gotten around to it."
- I'm Sumana. I'm the first link for Sumana on major search engines
- Can someone time me? Tell me when I've gone for 20 minutes?
- I talk fast, sorry non-native speakers.
- Mostly a US-specific, talk, sorry, but will try to make it not entirely tech-companies-specific
- Please feel free to liveblog, tweet, etc. I'll be putting up notes later, I hope this week
- This is not an Open Source 101 talk.
- driver v supporter (see "Learn Tech Management in 45 Minutes")
- I'll take moments to answer questions within the talk
Names have been changed but stories are real.
Sohcahtoa Software is a 50-person consultancy in a major US city. They use a lot of open source software to make and improve web sites and web apps, and might be working on a platform product in the next year or two.
If you have heard of Sohcahtoa Software, it's because they make a plugin that probably ten thousand people use. It has a great UI and makes people's experience of the internet better. They've released the source. But there are patches pending from the community, have been for months, and no one has gotten around to responding at all, much less reviewing and rejecting or integrating them.
But the poor community management kinda goes both ways. Because one time Ben found an issue with a driver he was using. And he wanted to fix it. You know, make a real fix, one that would improve the software for everyone. So he tried to talk with upstream. There was no one in IRC, so he explained his question on a mailing list. And the upstream developers were really dismissive and unhelpful. They didn't help him get the guidance he needed to do a real fix and merge it upstream. So he just did a workaround for his specific situation.
Then there was Bellwether and Guster. The team was using Bellwether and found problems in how well it worked with REST. They talked a little bit to the Bellwether maintainers, saw that they weren't going to improve those bits on their own anytime soon, and started working on an alternative framework, Guster, to deal with that, hoping to release it publicly. Guster is pretty useful, and is now in internal use. It was awaiting some final polish before release. Then the main Guster developers, the people who would have been the maintainers, left the company. Bellwether now has independently developed some of the desired features, not all, and Guster is still in internal use but not released publicly. In the long run, this will cause more work.
Recently the company had a contest to improve that one plugin. They knew about some datasets that the plugin didn't work so well with, and they thought it would be fun to turn those test cases into a little contest. But they didn't open it up to the public. They didn't even solicit more test cases from the user base. They ran the contest internally.
When I brought up that question -- why'd you do that privately instead of making the contest public? -- my contact sort of paused and said that no one had even thought of doing it outside the company. The question never even came up. He also doesn't quite know how copyright works for the stuff he writes at work -- what process he'd have to go through to get legal approval to contribute something to an open source project, or whether he needs to at all.
- Does anyone briefly want to explain why I said that?
- According to a few Googlers: the reason why so many Android changes never made it back into the kernel is time and community relations. Engineers at Google did not have the time or the temperament to effectively collaborate with the kernel developers and coordinate the merge. So now there's pointless forking.
Another story that's more rubbernecking than anything else:
"About ten years ago I worked at a place that allowed email ONLY, no web, no IRC, no instant messenger. And all subscriptions to mailing lists had to be approved by the VP of engineering, and only ONE developer would be allowed to subscribe to any particular mailing list, so if you had a question for the Win32 mailing list, you had to talk to the developer who was the 'contact point' for that mailing list and have him submit the question on your behalf. Of course he would just ignore your request and go back to what he was doing. If you tried to subscribe to some other mailing list off a LISTSERV, the VP would say 'Anthony is already subscribed to a Win32 list, why do we need a subscription to another one?' Please note that there was no cost associated with these, just sending a 'subscribe' email.
"Anyway, internet access was FORBIDDEN. Some of the developers set up phone taps to their desk line and would connect to their home dialup accounts just so they could look up reference information. One guy was found out doing this and was fired. So then people could only do it at night after management had left, which was OK since we were working 16 hour days, 6 days a week at the time.
"We got invited to participate in a working group for a standards committee for some things that we were key in. After I got back from the first meeting and reported on some advances that I had learned our competitors were working on, this caused a commotion in management. They met with legal and then I was asked to sign a paper saying that I agreed contractually not to speak to any employees of competitors at the meetings. I pointed out that every single person at the standards meeting was a competitor. So they said don't talk to any of them. I said there was no point going to the meetings then. So they sent the company attorney instead. He had NO knowledge of engineering. He would make uninformed remarks at the meetings and take notes, then return and discuss the results with the vice presidents. The engineers were placed out of the loop regarding what was happening in the standards committee and when they finally agreed on a standard, our hardware could not support it. We ended up making no sales after a $11 million investment and the company went out of business.
Tuesday, July 11, 2006"
PROBLEMS & SOLUTIONS
- Copyright assignment.
- SFLC: "the best place to get these assurances is usually in the contributor agreement. This is done in a couple of ways: some projects ask contributors for whom this is an issue to get a written disclaimer of copyright from an authorized agent of their employers (this is useful even for projects with no contributor agreement, of which there are many); others require the contributor to merely represent that they have the necessary authorization (although this is problematic, since if the employee doesn't have authority to bind the employer to the agreement, it won't be enforceable against the employer). If a project receives a large number of contributions from employees of a particular company, it might enter into a blanket agreement with the company covering all of the contributions."
- think about Fedora contributor license
- work with the community better! Take the time, do the things you already know you need to do, be disciplined & consistent about being n00b-friendly. These people will end up your users, contributors, and evangelists.
- According to Karsten, what I said: "FLOSS project leaders - work with your community. Just do it, you know how to do it, stop whining."
DEVELOPING A FLOSS CULTURE [longterm]
So, obviously, don't wall yourself off. Scott's story is an extreme.
- But engaging with open source is a two-way street; if you just grab a code dump and mod it forever without merging back, you'll end up a sad panda
- There is no such thing as closed innovation
- What I actually said: Innovation is a two-way street. There is no such thing as innovation in a closed bubble.
If you don't have FLOSS, what do you have? Plaque. It will build up between your teeth and seem solid but in the end it will destroy you
- Managers who didn't start in tech don't inherently understand why you should use, give back to FLOSS
- culture comes top-down from knowledge, experience, & values
Managers: help your developers learn to be better engineers, & be their advocate
Internal marketing with the higher-ups
- If you fight, don't fight alone. Leverage existing resources & people. Hold lunches, become the authority
- If you write or find material to send to executives, as Addie notes I said: "It's especially helpful if you create something that's approx. the reading level of Delta inflight magazine, so it's suit level"
- Bring in someone from Google's Open Source program office, the Participatory Culture Foundation, the White House's tech outreach folks (they're using Drupal), OSCON & OSB folks, GNOME, allies in your industry to educate
- I'll be collecting a list of some articles you can email around, about the benefits of open innovation
External marketing -- useful if your clients have any clue or your salesfolk are willing to educate, but be cautious because some do not care
- Brag about it; be a journalist, have your PR people trawl for evidence of FLOSS citizenship within your company & trumpet it
- when a developer spends a day cleaning up code to contribute back upstream, charge it to the PR budget; have your press folks write a case study/press release.
- improves morale, provides an example to the rest of your organization
Tuned employee performance criteria and appraisals -- not nearly as big, urgent, salient a factor as I thought they were
- No one brought this up, but you could put FLOSS citizenship in your performance review process -- I can talk about that more offline
- Performance criterion/goal: upstreaming, helping on mailing lists, blogging, conferences, commits, code reviews, wiki gardening, documentation, helping on IRC, reporting bugs
Developers & managers: dealing with unambitious or not-with-it coworkers
- company culture...are you and your colleagues aware that you're in an environment, an ecology, an industry? thinking of the longtail?
- compare to "37% of all adults lack exercise" stat. Probably US-only and they didn't even think to mention that. Don't default to isolationism.
- get conference passes to nearby FLOSS conferences, share them out
- let them know about user groups
- If your developers show some minimal altruism, they'll get reciprocity from that community & you can recruit better people
- Improves your developers' skills (code review, teamwork, domain knowledge, some morale)
- If you have trouble recruiting staff, this is a free perk
Set up a one-stop-shop -- John Jawed mentions Yahoo example
- BSD more palatable than GPL
Negotiate your exclusions in your contracts; you have the upper hand
Kirrily Robert would negotiate, every time she got a job:
- "with manager approval, I am allowed to contribute code I write at work to FOSS projects that don't compete with the company's core business"
- manager's discretion
- example: working at a real estate-related company, she contributed Perl testing code to CPAN
- you might have a tougher time of this if you need to contrib somewhere that requires copyright assignment
- note whether you will contribute under your or employer's name
- From Addie's notes: the moonlighting talk and exclusion negotiation discussions cover part of 'the gentle art of career self-defense'
- encourage your coworkers to use this clause
TIME AND PROJECT MANAGEMENT [long- & short-term]
Be a good engineer, which means thinking holistically in terms of the project & the firm. Upstreaming patches and maintaining a usable upstream is already good engineering practice!
- how does this save money, mitigate risk; help wrt features, time, money, or quality
- what are your project's & company's objectives?
- If this doesn't work with those, you might have to drop it....for now, & start thinking more longterm
- if you can link it, articulate that link to yourself, so you have it ready in case you're asked
- As Karsten summarizes: Be prepared with a "why it benefits us" answer for your FLOSS work.
- Allow more rampup/investigation time when starting a project
- you are designing elegantly & exercising discipline to ensure that upstream will stay useful; avoiding accruing technical debt
- build, borrow, or buy?
- Insurance re total development cost
- a good time to separate out things you can keep open & public; separating layers to keep dev more flexible in future, plan future integration
- obviously you don't open the source on core competence, on drivers, but on supporters.
- AUDIENCE QUESTION: WOULD THIS HAVE HELPED WITH ANDROID?
- include it as a TODO, not just a nice-to-have
This is not a 101 talk, but firms should contribute back to FLOSS for reasons like:
- Don't get separated from trunk like Android, Sohcahtoa
- then again, maybe you mean to fork....driver vs supporter, core competence/revenue generator
- You're already using FLOSS components; you can influence direction of development
- Examples: WebKit, Scott's company
- There may be a compliance reason that you have to contribute back changes
Leverage your, superior's authority and social capital; company counsel will believe the VP of Engineering, not you [Byrne Reese]
- They can start a process. Like Yahoo -- needed to iterate
If you start something internally, and the maintainer leaves, make a decision to hand it off to someone else internally, or at least ask the maintainer to throw it over the wall with some minimal PR on the way out?
Not that I can advocate these tactics in good faith, but....
- sometimes, just do it & spin it well to your boss later
- or, build it into the project plan properly without flagging it
QUESTIONS, COMMENTS, TIPS
From Addie's notes: "Asking questions nicely, being that innocent pain in the ass" can help your team avoid isolationism
- Byrne Reese of Endevver
- Eric Fischer
- Kirrily Robert
- Karl Fogel
- Seth Schoen
- Michael Rehse
- Aaron Williamson of the Software Freedom Law Center
- Leonard Richardson
- Henry William Chesbrough's "Open Innovation"
- Karl Fogel's Producing OSS
- SFLC (Software Freedom Law Center)
- "Corporate change: Contributing to open source", posted 8 Dec 2010 by Daniel Doubrovkine on opensource.com
- Five questions about open innovation with Stefan Lindegaard
- Dave Neary's "The Cost of Going it Alone", 2011