RIch Sands and Simon Phipps share some of the lessons they learned about driving organisational engagement with open source develiopers ... with an FAQ. (from the FOSDEM 2018 Community Devroom)
answers yourself! ◦ Test and refine strategy. ◦ Get everyone to agree. ◦ Create consistent messages. ◦ Establish trust through transparency. If you can answer the hard questions intelligently, you’ve got a coherent strategy and message.
• Yes! Devs know the hard ?s and expect answers. Q: What if they won’t like the answers? • Don’t “spin”. Truth earns respect and trust, even if it isn’t what they want to hear. Maybe they tell you they won’t use your technology. If that is a problem, change your strategy. Q: What if we don’t know the answers? • Say “We don’t know”.
you choose a license like BSD or Apache v2? A: Sun had several objectives in mind in choosing the license for the JDK source code. We wanted to: • Drive more adoption of Java SE, especially within GNU/Linux distributions. • Minimize the likelihood of incompatible forks. • Engage a broad cross-section of the open-source communities. • Protect and enhance the investments of those who have licensed and chosen to support the Java platform. After extensive analysis and consultation with experts both inside and outside of Sun, we determined that of the choices available, the GPL v2 + Classpath exception license paradigm is most likely to achieve these objectives. We know that this choice is unlikely to please everyone but we believe it offers the best balance of opportunity for developers and Sun. Hard question. Unpopular, but complete and truthful answer: drive adoption, while preserving the value of Sun’s binary Java licensing business and protecting compatibility. “Balance” - meaning, Sun was unwilling to choose a license that its leadership believed would damage Java’s “Write Once, Run Anywhere” value proposition, or Sun’s OEM licensing business, but wanted the benefits from open sourcing the platform. This was the compromise arrived at after months of fierce internal debate.
Transparent. • Complete. • Intellectually deep. • Answers to hard questions. • Good navigation. • Motivation: why, not just what. Topics: • What you’re announcing. • General and goals. • Business model: how everyone succeeds. • Legal: licenses, I.P., terms of participation. • Schedules, roadmaps, releases. • Community and infrastructure. • Ecosystem questions. • Where to find more information. The general FAQ doesn’t replace documentation. Have a separate FAQ for technical usage questions.
Start early! • Brainstorm ?s with a cross-functional, empowered team. • Divide and conquer to develop answers. • Expose and resolve strategic conflicts and weak planning. Use the FAQ to engage leadership, force strategy decisions and concurrence.
◦ A marketing/messaging expert, ◦ A compelling and clear writer, ◦ A great team leader, ◦ Skilled at engaging with your developer community. Your community manager, of course!
The strategy must have a clear path to deliver what leadership wants. To gain alignment, they might need to: ◦ demand compromises, ◦ change incentives, and ◦ hold everyone accountable. • They’ll have to embrace transparency. • Driving adoption often requires them to give up control. If leadership isn’t on board, watch out!
They’re right! Explanations and motivations in the FAQ open your organization to scary new legal risks. • Legal language defines rights and responsibilities with certainty. Plain language seems risky to lawyers. • But developers aren’t lawyers, and don’t hire lawyers. They need the FAQ to explain in plain language. Hard to solve: Leadership must charge legal with minimizing risk, but ultimately with being a partner in success.
12, 2006, one day prior to Sun’s initial code drop for OpenJDK, a senior executive tried to kill the Open Java FAQ, replacing it with a short, spin-heavy version. • By then, enough other senior executives were sold on radical transparency to turn back this coup attempt. • But key employees had to threaten to quit in protest first. Be sure your top leaders have your back!
authoring tool with change tracking. • Publish near code: Github Pages, an organization’s forge, wherever your community lives. • Simple: linked HTML TOC, number the questions, give each a URL, avoid “eye candy” Javascript. • Moderate but publish all comments, both good and bad. • Evolve your FAQ. Include “What's New?”, version/date. Don’t get fancy. Follow your community’s norms.
consistent, detailed set of messages, the FAQ should be a primary source. • The FAQ can streamline MarComm. Nearly every ? will be answered in depth, and the FAQ can train spokespeople. • Your FAQ can also inform speaker guides, keynotes, executive messaging. When even hard questions have clear and true answers, staying “on message” becomes much easier.
to embrace radical transparency? • First prove it works, with a pilot project. • Introduce your leadership to community thought leaders. • Expect pushback. You’ll know you’re getting there when your executives are uncomfortable. Patience and demonstrated success wins over skeptics and changes culture.
with a lot of this content: https://rsandsconsulting.com/the-faq-faq/ • The Open Java FAQ as archived by the Iced Tea project: http://icedtea.classpath.org/openjdk/java/faq.jsp.html • Android: https://source.android.com/setup/faqs • Creative Commons: https://creativecommons.org/faq/ • Apache: https://www.apache.org/foundation/faq.html
webmink
bkuhlmann
scalar
pangmoo
kazumain
manfredsteyer
konifar
quramy
inouehi
ski
ivargrimstad
satoshi7190
schacon
bcantrill
dougneiner
hannesfritz
colly
kneath
tammyeverts
chriscoyier
destraynor
skipperchong
cherdarchuk
jeffersonlam
![(Frequently Asked) Questions? Rich: [email protected] Simon: [email protected] Rights information: Comics](https://files.speakerdeck.com/presentations/1c6e49ca0edf4f978724e49746959b65/slide_20.jpg){kind=link}