Zero Adoption: Lessons Learned From Failing at Open Source
I'd love to tell you a story about how the software I created helped my community. Sadly, I can't: nothing I built ever found an audience. This talk is about how I failed to reach a community, about why it doesn't matter - or rather: what I learned from being stuck in an open source team of one. For years I was convinced that the success of an open source project was determined by the usefulness of the software. My imaginary blueprint of open sourcing was: Build something useful Open source it Everybody wins It turns out that it is much harder than that. This talk is about how I built several tools that would help the UX community to deliver awesome products with a great experience, while never finding an audience for the tools. We'll look at all the mistakes one can make and what to do instead to build a thriving community. And even if you don't find an audience: Zero adoption does not mean zero value. We'll look at how there is great benefit in building and publishing things, if not for others then for yourselves.
Recommended
Recommended
More Related Content
What's hot
Similar to Zero Adoption: Lessons Learned From Failing at Open Source
Similar to Zero Adoption: Lessons Learned From Failing at Open Source (20)
More from Memi Beltrame
More from Memi Beltrame (20)
Recently uploaded
Recently uploaded (20)
Zero Adoption: Lessons Learned From Failing at Open Source
- 3. Memi UX Designer Research Design Prototype
- 4. Prototype UX Designer Highly interactive Prototype feel real Simulate behaviour Use realistic data Visual design secondary Memi
- 6. Frontend Backend The anatomy of the Full-stack
- 7. „Frontend“ „Backend“ The anatomy of the fake-stack
- 9. It’s amazing It can do things that no other design tool can I make a living using it
- 10. It’s open source No one else uses it. Zero adoption.
- 11. How and why I failed at open source
- 12. 2010 Prototyping a pain, Testing is a joke.
- 13. 2010 Most of today’s tools were either not yet born or just not good enough.
- 14. 2011 Scratching my own itch
- 16. „Our employees in the field need to go on our intranet over their mobile phones.“
- 17. We needed a tool to prototype mobile experiences with real data It was clear that „prototypes“ like these would not be enough to see if we were going in the right direction.
- 18. A tool like this (That’s the actual prototype. It still works, even after all these years.)
- 19. A tool to prototype mobile experiences with real data This is how Protostrap came about
- 20. 2012 „Let’s open Source it“ „This is really helpful!“
- 21. ¯_(ツ)_/¯ We did. Nobody cared.
- 22. Assumption ★ Build something useful ★ Open source it ★ Everybody wins
- 23. Assumption ★ Build something useful ★ Open source it ★ Everybody wins DREAM ON
- 24. Assumption ★ Build something useful ★ Open source it ★ Everybody wins
- 25. Assumption Define useful ★ Build something useful ★ Open source it ★ Everybody wins
- 26. Open sourcing is like handing out the keys to a workshop
- 27. A messy one.
- 28. A messy one. No lights, just a torch.
- 29. Assumptions II ★ They don’t get it ★ Designers don’t care ★ It’s because I’m not using X ★ More tweets will fix it
- 30. Introspection took a while to kick in.
- 31. Mistakes ★ no documentation ★ no allies ★ no plan/roadmap ★ no frequent releases ★ no process
- 32. Documentation It’s the hardest easy win.
- 33. Documentation It’s the hardest easy win. ★ It’s hard to document so others understand ★ Documenting software is like math: examples go a long way
- 34. Allies many brains are better than one. ★ find allies early on ★ true allies help you focus ★ development partners, mentors, advocates, sponsors
- 35. Make a plan ★ Figure out your pipeline ★ Share it so people see that the project has a future ★ Maybe the things you’re planning add enough value for adoption
- 36. Make frequent releases ★ People see that the project is active. ★ Don’t neglect minor releases: they are the pulse of the project
- 37. Process Relese early, release often is hard ★ Writing is rewriting ★ Focus on benefit not features ★ Find the balance between new and refactored.
- 39. Help people become users: Help them overcome the friction that comes with adoption.
- 40. Friction of adoption ★ What are you replacing? ★ To which extent? ★ What burdens are you creating? ★ Is the benefit worth the hassle?
- 41. Users will be your most valuable resource
- 42. Focus on users first Users become collaborators ★ What do they need? ★ What do they say?
- 43. Zero Adoption ≠ Zero Value
- 46. Stay unique & keep doing stuff