Building a developer community in an enterprise world

Editor's Notes

• #2: Talk about our experiences at IBM of building the WASdev developer community around Liberty, a Java application server. Developer Advocate, rather than Tech Evangelist (Tom). Focus on people side of tech. Psychology and human factors. 13 yrs at IBM, Tech writer (7), UX designer (4). All on enterprise middleware. Since June 2013, I've been developer advocate for the WASdev community around our Liberty application server, which includes managing and editing the website. Outside work, I present on the Ubuntu Podcast on technology and open source, and I've co-organised and run open source community events, like OggCamp.
• #3: Just as a bit of background, Liberty is a Java EE application server. Java EE is an extension of the Java language, providing extra capabilities that make it easy to create websites, such as security, websockets, batch processing, and so on. If you're not into Java EE, all you need to know is that there are two IBM Java application servers that you can run your Java EE apps on. They can do much the same thing, but WebSphere Application Server (WAS), 20 yrs, stable, flexible, powerful – great for ops/admins. For developers, not so much – slow to restart whenever change something, big 2GB footprint and memory, complicated to set up. WAS Liberty was designed to have better developer experience - more lightweight, modular, automatically redeploys changes in your apps, no restarts required. Proprietary but includes 40% open source in a full installation. Still good in production. From the start, part of developer experience is strong community so as well as building a new application server, we worked on building a Java developer community, which we call 'WASdev'.
• #6: We provide free resources and free downloads to help Java developers try out Liberty for themselves and be productive. Published on our community website, WASdev.net. Also publish source code of samples on Github, have tags on StackOverflow, IBM-hosted Q&A site (dWAnswers), Slideshare, Twitter, YouTube, et al. Also publish some info on other people's sites, when appropriate, and try to promote blog posts and other relevant writings of non-IBM members of the community. Accessible to devs - reduce clicks to downloads, inc simplifying IBM's process for accepting licence. Developers (Java EE, specifically) actively engage with us and with each other in using Liberty. Share technical expertise through various means (eg responding to each other's questions on forums). Tom, Tech Evangelist, attends several conferences a year but we also try to get Liberty developers out to as many events as possible too. Eg in the past year, QCon, Devoxx UK, Vixxed Days, At The Frontend, JFokus, Øredev, GOTO, Chef Community Summit, Agile on the Beach... Have a strong basis of credibility, trust, and authenticity; eg talk directly with Liberty developers, be open about what we do and who we are. Have regular betas so developers can see what we're doing and give feedback. Also, just show that we're real developers too – not some big blue, corporate, faceless blob.
• #8: Back in 2008 (before Liberty), at Devoxx dev conf whiteboard session, this happened... Back at base, everyone put their heads together and...Liberty release June 2012 (more attractive to dev audience) The dev team realised when we released Liberty that it's not enough to create great technology; need community. We needed to demonstrate the much improved developer experience, help developers be productive with Liberty. Surprise to me when researching this talk, that the need for this approach was never disputed by dev or product management. Turns out that the idea of community was not new to the team.
• #9: The Liberty development team previously worked on the Apache Aries project, which (as it sounds) is an open source project, and it provides a component of Liberty. The team even then had a technical evangelist, Zoe Slattery, since about 2009. Before Aries, Zoe had been technical evangelist on another project with the PHP community and had contributed a load of IBM's PHP tests back. So she had understanding of OSS community and she helped the Aries team be a good OSS citizen. Among other things, she organised community events at IBM locations, like a UK Apache Retreat on the lawns at IBM Hursley. She also organised BarCamp London at IBM's South Bank offices in London. Having a load of developers from various companies staying overnight at a highly security-conscious IBM location went surprisingly well. Except for the man's leopard-print thong that someone flushed down the loo, causing havoc in the ancient plumbing... Laid the foundations for developer relations and community in the Liberty team culture.
• #10: We were going to build a community so we, of course, needed a website. But it had to be something different from the corporate ibm.com website (updated quarterly, corporate language/style, not interactive, executive and tech managers audience - not devs). We wanted to regularly update, be less formal style, variety of types of content, downloads (inc betas), and capabilities for forums, and generally support interaction between the Liberty dev team and rest of community as well as generally between community members. Also wanted an easy-to-remember and type URL - not a long extension of an ibm.com URL. WASdev.net name was meant to emulate the success of Jazz.net, creation of the Rational brand within IBM. Rational was a company acquired by IBM and specifically focused on developers when the rest of the software org was not. Jazz.net was (and still is) aimed at supporting developers collaborate on tasks throughout their development lifecycle. It's IBM-owned but looked and felt a lot fresher and less corporate than the ibm.com site at the time (eg blogs, events, look and feel). Jazz.net was the kind of community that WASdev.net wanted to be.
• #11: Unfortunately, Jazz.net wasn't part of IBM's developerWorks organisation at the time and dW didn't agree. dW is an org within IBM that produces a popular website of articles for developers - get a large number of page views a day and their view was: why wouldn't we want to be part of that? But we were expected to fit in with their view of community, yet it was clear that their communities were just a readership of their website and weren't very active or engaged. They also expected us to rigidly follow their look-and-feel template with multiple headers and footers. Their site had limited capabilities and resisted adding things we requested, like embedded discussion and Q&A forums. WASdev.net did actually end up being hosted by developerWorks (a combination of cost and politics) but with the compromise that we could customise the site so that it could have its own look and feel to some extent (though even then requesting new capabilities for the site was onerous). By the end of 2012, after the first release of Liberty, developerWorks were more convinced and were interested in using WASdev.net as a template for other developer sites. Then developerWorks was reorganised with a team set up specifically to build developer communities like WASdev.net. That team was led by Seth Packham who had been on the original Jazz.net team. They took on WASdev.net as a guinea pig for their new approach and just as I joined the team in May 2013, WASdev.net moved on to their new Wordpress hosting infrastructure with a brand new look and feel. And part of their remit was to challenge IBM's traditional processes in the name of a better developer experience. They're a great team to work with and they do a great job. Being first, we'd had the pain of changing and challenging but worked out for us, and for developerWorks.
• #12: So we got our website. We just needed to populate it now. And then keep it fresh and responsive so developers would want to keep visiting it.
• #13: After the first release of Liberty (June 2012), we instigated a weekly publishing schedule. Every Wednesday, at least one article or sample must be published so that the site stayed fresh and remained useful to developers. It's hard work keeping up this kind of schedule when dependent on developers producing the content around their other job responsibilities. Attitude then was that it was 'extra' to their day-job. The responsibility for making this happen fell to a developer, Ross, around his own day-job. Ross remembers coming in on Monday morning, fresh from a 3-week caffeine detox. By Tuesday he was on Red Bull. He had many late nights and the job unofficially became full-time. At which point it was recognised that the website needed someone full-time on it. That's when I joined.
• #14: While I too had some stressful Wednesdays, we were starting to get more contributions from the dev team so it got a bit easier to build up a pipeline of articles. I'm not a developer so extra important to motivate team. Which is difficult when writing articles and samples is seen as 'in addition to' the day-job. We had an important release of Liberty in June this year and there was a new keenness to have lots of fresh new content on WASdev.net. An email from management (executive!) helped encourage the team to volunteer to write articles and sample code that we could publish on WASdev.net. It worked, and it's continuing to work now. Devs now create tasks for themselves that are not about writing product code but writing articles and sample applications for WASdev.net. It's part of their job, not an extra to do in spare time.
• #15: While writing articles and samples is now seen more as part of the developer's day-job, other types of contributions to community are less so. For example, answering technical questions on Stack Overflow and IBM's dWAnswers site, interacting with the community on social media like Twitter, and speaking at developer conferences. I think it's partly because these things are less easy to timebox than writing an article. Social media participation and answering questions is on-going and never really done. Some developers (like Holly) are already keen and out there doing stuff. Others are interested in doing but aren't sure how. That's where I can help encourage and support them, whether it's suggesting ideas for conference submissions and reviewing abstracts, helping them get set up on Twitter or StackOverflow, helping them understand what they can say and allay fears that they'll say something wrong and get sacked. An email from management won't speed this up. The Liberty developers need to come to it in their own time and can't be forced. Some will never be interested in participating, and that's fine. My role is to identify who is interested and who could benefit from building a reputation in the industry and help them with anything they're unsure about. The strength of social media is its authenticity. Good tweets, answers, posts come across as the contributor's genuine belief and interest. There's no benefit in forcing participation in social media because that authenticity would be lost. Let them do the things they're good at and are motivated to do.
• #16: The most frustrating thing I've experienced in as developer advocate has been our relationship with Marketing. As developer advocate, I'm part of the Liberty development team ('engineering'), not Marketing, which is a separate org. I've come to learn that Marketing and Development have different but complementary roles with very different goals, metrics, and timescales. It's these differences that have caused us to clash several times.
• #17: Our relationship with our marketing org was, until recently, frankly rubbish. We felt they didn't understand developers and we were very protective of WASdev.net and didn't want it turning into a product marketing website. Things only really improved in the last few months, when I think an IBM reorganisation changed the Marketing organisation's structure and focus to do more developer marketing. We also acquired, in the development team, a manager with some background in marketing, which has helped us communicate better, I think. I think we now work in more complementary ways with our marketing teams, even if we still frequently disagree on how to do things.
• #18: Marketing are good at generating awareness and 'hooking' people in. Even developers appreciate shiny things. What developers tend not to appreciate is an expectation that they'll be *convinced* by the shiny. Marketing focus on high-level solutions without the detail of how to make them happen in practice. Devs need detail and the opportunity to make their own decisions about software based on experience. We in dev can provide developers with all the resources and technical expertise they might need to be able to try out and evaluate some software before going on to decide for themselves whether it's the right software for what they need. The main point of contention between us and marketing was about our decision not to require developers to register before downloading Liberty (which is free to developers). We knew it would put people off trying out Liberty (we found 60% drop-off the page when a registration wall was added). If anyone did fill in the form correctly, they wouldn't appreciate getting cold-called by Sales and wouldn't have authorisation to buy anything anyway! To us, it was more important that as many developers as possible actually tried out the software – and then decided to use it. Unfortunately, the marketing teams had to regularly report progress back to the business, and sales leads (however invalid we felt they were) were the way they had to do it. Got to the point where they would have to work around our objections and sometimes gave Liberty less attention in favour of other products as a result of our perceived awkwardness.
• #19: Building a developer community is a very long-term, organic process. It will never be 'done'. It can only be improved upon and developed. And because it's mostly about people, it can't be forced or speeded up to fit into a financial quarter. In Liberty development, we've been lucky to have really supportive management, right up to executive levels who understand that it's hard, or even impossible, to fully quantify community vitality. While we track things like the number of downloads of Liberty, number of visits to WASdev.net, and so on, I prefer more qualitative indicators of success, in particular, how warm and fuzzy does something make us feel? Having a bunch of IBMers start following us on Twitter and retweeting a link means much, much less to me than Liberty getting mentioned in the latest Docker newsletter, or the Oracle evangelists blogging about Liberty, or that someone who's never previously mentioned us on Twitter just said something about us. Despite our differing approaches, in the past few months, I think there's been more respect grown between our development and marketing organisations. I notice now that marketing do defer to us a bit more on the detail of how to engage with developers instead of wading in and potentially having the opposite effect. In turn, we're more open to considering their requests and suggestions, where previously we'd have been inclined to reject them out of hand - just because they're from marketing.
• #20: For me, day-to-day, the big challenge is in ensuring that the WASdev.net site remains 'for developers, by developers' as it claims.
• #21: With the success of WASdev.net, in terms of numbers of visitors each month, has come the perception (within IBM) that the website is there to be a publishing platform for any marketing material, customer support documents, or documentation that can't go anywhere else. It's usually obvious whether someone contributing an article has thought about the audience if I ask them who it's aimed at and they say 'everybody' or 'Liberty users'. It generally gives away that they're not really thinking about the audience so much as just wanting to broadcast information that they feel should be 'out there', with good intentions but not necessarily with WASdev's aims in mind. UX designers talk about primary users vs secondary and tertiary users. Java developers are our primary users. IT managers, CTOs, operations people are welcome to read WASdev.net but they're not our primary users. If we just throw up content on WASdev.net for 'everyone', it dilutes the message that we want to build a relationship with developers (specifically Java developers). Developers will get fed up if they have to sift through irrelevant content about, say, how to cluster 10k servers, before they can find a useful article about how best to write an application that uses WebSockets. WASdev.net is there to help build the WASdev community. So everything we publish there should support that.
• #22: So I frequently have to say 'no' to articles. Which can be really hard when the author has already written it and had it reviewed, with the expectation that it will then just be published. It can also be difficult if the request comes from someone senior or the article is about an area of the product I know little about. Sometimes, as my manager kindly pointed out recently, refusing to publish articles is "potentially career-limiting" for me. Such as objecting to publishing an article written by one of our executives. My view was (and is) that the article wasn't of interest to a developer audience. It ended up being published somewhere more relevant and wasn't a problem in the end. But it's not always that easy. We win some and lose some. And there are a lot of grey areas. It is getting easier, mostly I think because I'm getting better at articulating why some content is appropriate and some isn't. This has come as I've learned more about the product, more about Java EE, and more about Java EE developers.
• #23: To help with my learning, one of the first things I did when I joined the team was to build an empathy map of the Java EE developer. An empathy map is a user experience design concept that IBM Design Thinking uses. Basically it's a way to capture the information that would be used to build a user persona. I documented what a Java EE developer: * Hears (instructions and feedback) eg recommendations from other devs on best tools to use * Feels (values) eg frustration at lack of productivity because of slow server restart times * Does (actions) eg attends developer conferences * Thinks (expectations and reactions) * Sees (environment and interface) * Says (quotes) Face-to-face meetings with devs, my experience of developers in OSS communities, online discussion threads on Reddit and other social media. You can expect honesty there; no, say what you really think! Having a clear definition (with examples) of the target user is useful for explaining why an article is appropriate or not for WASdev.net.
• #26: We think so. By quantitative measures, the lines are going up. By warm-and-fuzzy measures, we're definitely feeling warmer and fuzzier...
• #27: Having the beta (every 4 weeks) over the past year has helped us be more open, I think. From our perspective, we were able to talk publicly about features before they're released. The community was able to see our progress towards Java EE 7 certification and give feedback on it (eg Arjan's blog).
• #28: In 2015, we've still not completely shaken the WebsFear moniker. But at the end of last year, a Java EE developer called Liberty awesome. Which made us feel very warm and fuzzy.
• #29: Big shout-out to all the people who helped me prepare this talk.
• #30: Thanks to all the people whose photos I used with permission or under Creative Commons licences.