6 ms·

Ask HN: Marketing, DevRel and Evangelism working for Open-source

13 points by andreacavagna 5y ago

Hi everyone, Why is it so difficult to find a space to communicate your open-source project to drive adoption at scale? To recruit new people inside a new company, it's not easy to explain the open-source workflow to not-tech people, so most often, great open-source projects have lousy communication. Evangelism, like GitLab said (https://about.gitlab.com/handbook/marketing/community-relations/developer-evangelism/#utms-for-url-tagging-and-tracking), is essential. That's sure. But how to scale up a team to grow that skill inside the company? Is it better to grow it internally (logically, a founder is the best person to communicate his project)? But how a tech person can develop marketing and communication skills? Or the best way is to recruit a skilled DevRel person or instead of a marketing person and collaborate in creating great content?

andrewfromx 5y ago
Loui CK said once to another comic “be more funny” when asked how to have greater success as a comic. Don’t work on publicity or argue with club owners on time slots etc just be SO funny they can’t help but give you more of what you want. Same with OS projects? Just solve a real need SO well the world has to notice.
- andreacavagna 5y ago
  Solid point, but not everyone will notice it without someone telling you that the project even exist. the experience with my project (https://github.com/Noovolari/leapp https://github.com/Noovolari/leapp) is that if someone know the project it become an habit. And users tends to do WOM to other devs. But how to accelerate this project in a pandemic world, without the ability to partecipate to events in person?
mooreds 5y ago
> Why is it so difficult to find a space to communicate your open-source project to drive adoption at scale? You might ask instead "Why is it so difficult for my project to get adoption at all?" And this is the problem marketers have been dealing with for 100 years. The market is crowded, people are busy with their own lives. For OSS projects, both of these are even more true. So, how can you succeed? There's no magic bullet. There are many paths: * finding 10, 100 people that love your project and will evangelize it * spend money on ads to educate folks about it * spend your time writing great content about the space so that some percentage of folks will find it and then learn about your project * do direct outreach to people talking about the problems your project solves. I recommend articles by Amy Hoy and Alex Hillman: https://stackingthebricks.com/articles/ https://stackingthebricks.com/articles/ Patio11: https://www.kalzumeus.com/2010/01/24/startup-seo/ https://www.kalzumeus.com/2010/01/24/startup-seo/ and Karl Hughes: https://www.karllhughes.com/posts/marketing-management https://www.karllhughes.com/posts/marketing-management to learn more about techniques. Some of these articles are about products for $$$ but you are essentially asking folks to spend something more precious than $$$ (their time) so the principles are the same.
dnsmichi 5y ago
Speaking with my personal hat, not as Developer Evangelist at GitLab. I've joined my first OSS project in 2009 (left in 2020), and I have to admit - communication can be challenging. There are many best practices, little are documented, and projects and companies differ in their workflows. Here are few things I would encourage to do, or ensure to have in the very beginning: - Be transparent in all your decisions. Discuss in the open, record meetings for the public, share the meeting notes with everyone. If the project reaches a level where everything is discussed behind closed doors, and the only community updates are marketing blog posts and AMA threads ... that's a warning signal to lose your community. - Provide a handbook or documentation for all workflows. How to contribute, which direction/roadmap (in text form, not as a Git* issue board). Avoid so-called "product conferences" where you announce your roadmap. Instead, be open and have milestones to follow and discuss. - Community members should _never_ be treated as "you can submit a patch, but don't bug me further". Assume positive intent, and get feedback from problem reports. - Do not moderate or manage a community. Help seed the knowledge, and share trust with creating a governance structure (core team, community advisors, etc.). _Never_ silently remove granted permissions, losing trust. (that happened to me in 2020, I then made the decision to leave the OSS project Icinga after 11 years) - Establish a sense of belonging, share praise and encourage to contribute. Handle code of conduct violations with care, ensuring everyone feels safe. - Transfer knowledge in issue description, debug stories, reviews and encourage contributors to learn and follow. Coach and mentor fellow and future contributors. Take the time to thank everyone for their contributions. - Evaluate roles. A founder or backend developer as community builder may work in the beginning. Plan to hire additional resources who can lead the conversation, and involve teams when necessary. Encourage to learn new technologies and stay in the loop. - Document everything on the way, lessons learned, changes, what worked, what did not. Do retrospectives when announcements did not work the way you intended. Verify the defined actions. - Find evangelists/advocates in your company and community, give them visibility and push them in all collaborations. Ask friends who love social media, get the technical content writer champion, and give everyone a chance to learn and grow. Don't expect to hire experts. Instead, focus on existing DevRel communities and exchange knowledge and experiences within the community. - When you grow, do not hide as a leader. Be approachable with your team, and engage with your community. Coffee chats, meetups, etc. - follow the thought: Everyone can contribute. There's more to that, I've only shared a few quick thoughts now. Happy to chat more :) If you want to dive into the topic even more - I've shared my 10 years in OSS community story and all things learned in a talk at the Open Source at Siemens event in 2021. Slides: https://docs.google.com/presentation/d/1HnciJEQ8dDiHMaq1APg5WXA4mvcYQd9fdtvHicf-JyU/edit https://docs.google.com/presentation/d/1HnciJEQ8dDiHMaq1APg5... Recording: https://www.youtube.com/watch?v=yT63olXdS-I https://www.youtube.com/watch?v=yT63olXdS-I
karlhughes 5y ago
Lots of good questions here but I'll focus on two that I have the most experience with: > Is it better to grow it internally?...Or the best way is to recruit a skilled DevRel person or instead of a marketing person and collaborate in creating great content? I work with ~70 developer tools companies on devrel/marketing and the biggest killer has got to be founders who think they can just throw marketing over a wall to someone else. Initially, you as the founder need to become that skilled DevRel person. If not you, get a co-founder level person to help you. The truth is, in the early days, nobody else will care about the project like you do, so you need to be out there: - Writing about it - Demo-ing it - Talking about it (eg: conferences and meetups) - Talking to users and contributors Eventually, you'll need to build a playbook that another DevRel or Marketing person can execute, but you can't outsource this when you're still finding product-market fit.
- mooreds 5y ago
  I would add that you shouldn't just write about the project. That's kinda boring, to be honest. No one cares about your new feature, sorry :) . (I think this is implied in Karl's comment, but worth spelling out explicitly.) Write/talk/communicate about: * problems the project solves * the broader space the project is in * technical challenges you've encountered and overcome or sidestepped (for a tech audience) * how your customers are using the product to make their lives better
  - andreacavagna 5y ago
    This is the right target to hit, I think I've met the first two point but, there is still many things to do. Now I only have to upgrade my copywriting skills to pass better the message. What I noticed is, since the project is an open-source App, that is way easier to show the App in person instead of writing about it. I'm looking to events to be a speaker more than anything
    - mooreds 5y ago
      There are a number of services out there that can help you find CFPs (calls for presentations). * https://cfpland.com * https://techdailycfp.com * https://confs.tech/cfp I'll warn you it can quickly get overwhelming (at least it is for me) so a few tips: * have criteria for conferences (audience, size, location) * you can submit a talk without having written it. In fact, it's better if you haven't in some ways because you can tweak it. Just give yourself plenty of time if you do this. * you'll be rejected from lots of conferences * meetups are usually happy to have you. I wrote about this here: https://www.mooreds.com/wordpress/archives/3418 and this can be a great way to polish talks. * think about adjacent talks, so you can re-use components. I have talked a lot about various aspects of OAuth/JWTs and shamelessly reuse portions of them * spend some time thinking about how to sell the talk to busy conference attendees. Again, consider the larger context. No one wants to hear about 'how to implement OAuth with <my product>' but 'how to use OAuth to protect your APIs' is more exciting. 'How OAuth saved my bacon and made me a hero' is even better.
taubek 5y ago
DevRel and communication are full time jobs. If a open source project is depending only on volunteers it is hard to maintain communication at steady level. Not everyone can be a good communicator. You can learn communication skills, but sure it helps if you are an extrovert and not introvert. Who knows better than developer how developers think, how do they operate, what do they expect from products? Look at it from this perspective, can you learn a marketing person developer skills? You could but there is no need. He heeds to understand the facts about the product, target audience, technology landscape, etc. I personally think that the core ov the DevRel team should be developers that know the developer community. And then you build upon that.
- andreacavagna 5y ago
  great answer! thanks a lot, I'm thinking about a next career step in Community and DevRel things
  - ayewo 5y ago
    If you do decide to explore a career in DevRel, I maintain an spreadsheet of Developer Advocate opportunities: https://ayewo.com/exploding-career-opportunities-in-devrel/ https://ayewo.com/exploding-career-opportunities-in-devrel/
zriha 5y ago
Interesting conversations people, I am around 15 years in marketing, worked in SaaS, B2B/B2C environments on the C-level in past few year (I guess I am experienced). Now I work with open-source B2D company, when I am just entering into the world of developer marketing. And I can't emphasize enough how many times I heard - developers don't like marketing. My "developers" days finished back when I was writing lines of code on my Commodore C-64, so yeah, I am no developer. But I think, that marketing has a bad rep, along with media, public relations (I know PR means something different here) and other stuff, like the rise of awful "influencer marketing" that I hate. But one thing I learned all these years, working in different companies, markets, and even doing political campaigning. And that's my advice to you: - be honest - if it is difficult, then tell us, people who are not psychopaths tend to help other people, like we are listening your struggles and want to help you - be yourself - stupid I know, stupid expression by life coachers, but yeah, you are building something, but you are a person - so be yourself, and you will attract other people. - and last - give something back, contribute That's it. And yeah, DevRel and Marketing should be like one, like a team.

13 points by andreacavagna 5y ago

andrewfromx 5y ago

Loui CK said once to another comic “be more funny” when asked how to have greater success as a comic. Don’t work on publicity or argue with club owners on time slots etc just be SO funny they can’t help but give you more of what you want. Same with OS projects? Just solve a real need SO well the world has to notice.

andreacavagna 5y ago
Solid point, but not everyone will notice it without someone telling you that the project even exist. the experience with my project (https://github.com/Noovolari/leapp https://github.com/Noovolari/leapp) is that if someone know the project it become an habit. And users tends to do WOM to other devs. But how to accelerate this project in a pandemic world, without the ability to partecipate to events in person?

mooreds 5y ago

> Why is it so difficult to find a space to communicate your open-source project to drive adoption at scale? You might ask instead "Why is it so difficult for my project to get adoption at all?" And this is the problem marketers have been dealing with for 100 years. The market is crowded, people are busy with their own lives. For OSS projects, both of these are even more true. So, how can you succeed? There's no magic bullet. There are many paths: * finding 10, 100 people that love your project and will evangelize it * spend money on ads to educate folks about it * spend your time writing great content about the space so that some percentage of folks will find it and then learn about your project * do direct outreach to people talking about the problems your project solves. I recommend articles by Amy Hoy and Alex Hillman: https://stackingthebricks.com/articles/ https://stackingthebricks.com/articles/ Patio11: https://www.kalzumeus.com/2010/01/24/startup-seo/ https://www.kalzumeus.com/2010/01/24/startup-seo/ and Karl Hughes: https://www.karllhughes.com/posts/marketing-management https://www.karllhughes.com/posts/marketing-management to learn more about techniques. Some of these articles are about products for $$$ but you are essentially asking folks to spend something more precious than $$$ (their time) so the principles are the same.

dnsmichi 5y ago

Speaking with my personal hat, not as Developer Evangelist at GitLab. I've joined my first OSS project in 2009 (left in 2020), and I have to admit - communication can be challenging. There are many best practices, little are documented, and projects and companies differ in their workflows. Here are few things I would encourage to do, or ensure to have in the very beginning: - Be transparent in all your decisions. Discuss in the open, record meetings for the public, share the meeting notes with everyone. If the project reaches a level where everything is discussed behind closed doors, and the only community updates are marketing blog posts and AMA threads ... that's a warning signal to lose your community. - Provide a handbook or documentation for all workflows. How to contribute, which direction/roadmap (in text form, not as a Git* issue board). Avoid so-called "product conferences" where you announce your roadmap. Instead, be open and have milestones to follow and discuss. - Community members should _never_ be treated as "you can submit a patch, but don't bug me further". Assume positive intent, and get feedback from problem reports. - Do not moderate or manage a community. Help seed the knowledge, and share trust with creating a governance structure (core team, community advisors, etc.). _Never_ silently remove granted permissions, losing trust. (that happened to me in 2020, I then made the decision to leave the OSS project Icinga after 11 years) - Establish a sense of belonging, share praise and encourage to contribute. Handle code of conduct violations with care, ensuring everyone feels safe. - Transfer knowledge in issue description, debug stories, reviews and encourage contributors to learn and follow. Coach and mentor fellow and future contributors. Take the time to thank everyone for their contributions. - Evaluate roles. A founder or backend developer as community builder may work in the beginning. Plan to hire additional resources who can lead the conversation, and involve teams when necessary. Encourage to learn new technologies and stay in the loop. - Document everything on the way, lessons learned, changes, what worked, what did not. Do retrospectives when announcements did not work the way you intended. Verify the defined actions. - Find evangelists/advocates in your company and community, give them visibility and push them in all collaborations. Ask friends who love social media, get the technical content writer champion, and give everyone a chance to learn and grow. Don't expect to hire experts. Instead, focus on existing DevRel communities and exchange knowledge and experiences within the community. - When you grow, do not hide as a leader. Be approachable with your team, and engage with your community. Coffee chats, meetups, etc. - follow the thought: Everyone can contribute. There's more to that, I've only shared a few quick thoughts now. Happy to chat more :) If you want to dive into the topic even more - I've shared my 10 years in OSS community story and all things learned in a talk at the Open Source at Siemens event in 2021. Slides: https://docs.google.com/presentation/d/1HnciJEQ8dDiHMaq1APg5WXA4mvcYQd9fdtvHicf-JyU/edit https://docs.google.com/presentation/d/1HnciJEQ8dDiHMaq1APg5... Recording: https://www.youtube.com/watch?v=yT63olXdS-I https://www.youtube.com/watch?v=yT63olXdS-I

karlhughes 5y ago

Lots of good questions here but I'll focus on two that I have the most experience with: > Is it better to grow it internally?...Or the best way is to recruit a skilled DevRel person or instead of a marketing person and collaborate in creating great content? I work with ~70 developer tools companies on devrel/marketing and the biggest killer has got to be founders who think they can just throw marketing over a wall to someone else. Initially, you as the founder need to become that skilled DevRel person. If not you, get a co-founder level person to help you. The truth is, in the early days, nobody else will care about the project like you do, so you need to be out there: - Writing about it - Demo-ing it - Talking about it (eg: conferences and meetups) - Talking to users and contributors Eventually, you'll need to build a playbook that another DevRel or Marketing person can execute, but you can't outsource this when you're still finding product-market fit.

mooreds 5y ago
I would add that you shouldn't just write about the project. That's kinda boring, to be honest. No one cares about your new feature, sorry :) . (I think this is implied in Karl's comment, but worth spelling out explicitly.) Write/talk/communicate about: * problems the project solves * the broader space the project is in * technical challenges you've encountered and overcome or sidestepped (for a tech audience) * how your customers are using the product to make their lives better
- andreacavagna 5y ago
  This is the right target to hit, I think I've met the first two point but, there is still many things to do. Now I only have to upgrade my copywriting skills to pass better the message. What I noticed is, since the project is an open-source App, that is way easier to show the App in person instead of writing about it. I'm looking to events to be a speaker more than anything
  - mooreds 5y ago
    There are a number of services out there that can help you find CFPs (calls for presentations). * https://cfpland.com * https://techdailycfp.com * https://confs.tech/cfp I'll warn you it can quickly get overwhelming (at least it is for me) so a few tips: * have criteria for conferences (audience, size, location) * you can submit a talk without having written it. In fact, it's better if you haven't in some ways because you can tweak it. Just give yourself plenty of time if you do this. * you'll be rejected from lots of conferences * meetups are usually happy to have you. I wrote about this here: https://www.mooreds.com/wordpress/archives/3418 and this can be a great way to polish talks. * think about adjacent talks, so you can re-use components. I have talked a lot about various aspects of OAuth/JWTs and shamelessly reuse portions of them * spend some time thinking about how to sell the talk to busy conference attendees. Again, consider the larger context. No one wants to hear about 'how to implement OAuth with <my product>' but 'how to use OAuth to protect your APIs' is more exciting. 'How OAuth saved my bacon and made me a hero' is even better.

taubek 5y ago

DevRel and communication are full time jobs. If a open source project is depending only on volunteers it is hard to maintain communication at steady level. Not everyone can be a good communicator. You can learn communication skills, but sure it helps if you are an extrovert and not introvert. Who knows better than developer how developers think, how do they operate, what do they expect from products? Look at it from this perspective, can you learn a marketing person developer skills? You could but there is no need. He heeds to understand the facts about the product, target audience, technology landscape, etc. I personally think that the core ov the DevRel team should be developers that know the developer community. And then you build upon that.

andreacavagna 5y ago
great answer! thanks a lot, I'm thinking about a next career step in Community and DevRel things
- ayewo 5y ago
  If you do decide to explore a career in DevRel, I maintain an spreadsheet of Developer Advocate opportunities: https://ayewo.com/exploding-career-opportunities-in-devrel/ https://ayewo.com/exploding-career-opportunities-in-devrel/

zriha 5y ago

Interesting conversations people, I am around 15 years in marketing, worked in SaaS, B2B/B2C environments on the C-level in past few year (I guess I am experienced). Now I work with open-source B2D company, when I am just entering into the world of developer marketing. And I can't emphasize enough how many times I heard - developers don't like marketing. My "developers" days finished back when I was writing lines of code on my Commodore C-64, so yeah, I am no developer. But I think, that marketing has a bad rep, along with media, public relations (I know PR means something different here) and other stuff, like the rise of awful "influencer marketing" that I hate. But one thing I learned all these years, working in different companies, markets, and even doing political campaigning. And that's my advice to you: - be honest - if it is difficult, then tell us, people who are not psychopaths tend to help other people, like we are listening your struggles and want to help you - be yourself - stupid I know, stupid expression by life coachers, but yeah, you are building something, but you are a person - so be yourself, and you will attract other people. - and last - give something back, contribute That's it. And yeah, DevRel and Marketing should be like one, like a team.