Lessons Learned from Cultivating Open Source Projects and Communities
Introduce yourself here, JJ etc :)
- my email address
- texan, been in industry since 15
- works at IBM as a Developer Advocate for a year
- Worked at Chef before that, lived and breathed the DevOps way since 2011
This isn't a tools talk
- We all know that there are a ton of tools out there that help with managing and maintaining projects.
- I might mention some, but this isn't about how I used tools to do the job.
- This is a talk about the squishy stuff on what I've learned.
Scoping your project
- The _very_ first thing I learned about open source was how to scope a project correctly.
- Mention the Big Tent here, OPENSTACK failed because of the big tent
- The irony is the first project I was envloved in was a small linux distrobution called CRUX.
- FAQ
- IRC help
- Tested Ports trees
- Met Jaeger in real life _years_ later at VMworld, still friends today.
Personally-backed
- From what I've learned this is actually the majority of projects out there.
- Largest challenge is because it's your baby, and you scratching your own itch,
- You have to be the leader of the project
- Double edged sword, I bet there are a handful of people right now in the audience that have there own project or projects.
- You are the endall be all, it can be stressful.
Corporate-backed
- DEPENDING ON AUDIENCE
- This is, probably the majority of peoeple I am talking to
- We are privilged enough to be paid to help humanity use code
- Using computers to make their lives better.
- The challenge though is when a corporation backs your project, they ultimately runs your descitions.
- Google, shutting down projects
- Oracle eating up projects
Empathy for your audience
- Believe it or not, but as a leader or maintainer of a OSS your are a preformer and seller.
- You have to be constantly recruiting and "always on brand" for your project.
- This also doesn’t happen overnight, this takes months or years even of dead silence or a trickle of engagement then if you’re lucky might create a community. The scary thing is that because it’s all volunteers that help you, you have to continue to cultivate it, and if you or your project does something wrong you can lose all of your members overnight. Yes, it can take months or years to build it, and overnight people’s priorities can change and you can be left alone. It doesn’t sound all unicorn and rainbows, mainly because it isn’t; it’s hard and unforgiving.
- It's like attempting to start a meetup, you might find yourself in a room by yourself
Building and leading an Open Source community is like organizing a trash pick up in your neighborhood. No one cares about the permissions you had to negotiate to get the local board to say yes, they are there to help you beautify the area. It’s still good to feed them or celebrate the best workers, but in general, they don’t care about the back end at all.
- MENTION THE TRASH PICKUP ANALOGY HERE
- I wrote a blog post about it, if you're interested email me and I'll send you a link. https://jjasghar.github.io/blog/2018/03/23/leading-an-opensource-community/
Celebrations
- Talk about Celebrations here. Version 1 was released!
- You promoted a user to a maintainer,
- you found out that more then just you are using your open source project,
- these are all wins and should be vocalized, and celebrated.
- Nothing is too small to celebrate. take any and all wins you have.
Defeats
- With all celebrations there is the other side of the coin, defeats. Things break, things go off the rails, you have to own up to these things. If you ever want your project to be successful you have to have that transparancey. If you don't you'll never get the traction to keep your project going.
At th same time, being in our communities is draining, Adam Jacob here sums it up in a straight forward tweet.
Successful traits of open source projects
Trust
As obvious as this sounds, yes. Trust. You have to default to trust as a Open Source maintainer or creator of an open source project. You'd be amazed on how many people just throw code out there and don't trust anyone other themselves to change it. By releasing your code to the world you trust that many hands (that you still need to constantly recruit) make light work.
- This isn't just accessing the project
- How to access the community and things like that
I get it, slack is great. It's opened up a way for communication in a way we've never seen before. But IRC still exists, bigger then ever. You want your code and community to be accessable to everyone.
- OpenStack meetings every week same time with meetbot
- Communication through IRC for async
- SLACK is considered "OK" in the community now, be sure to address this.
Have a plan to move on if needed
Eventually you'll get bored. Don't lie you know you will. As an engineer or developer you have the trait to be a constant learner. Your project will get stale, crusty and possibly a burden. Some say this is a win, others become jadded and want to move on. If you where one of the luck ones that got a project adopted, it'll have to be continuly maintaned. So you'll need someone or someones to take up those reins.
So, have an exit strategy. Have a way to move on, hopefully in a constructive way, and who knows you might get some people to follow you to your next thing.
Honestly, is it even worth this hassle?
With who I'm speaking to, and if you've come to this talk, you probably have some level of debate in your head. You want to, or do, run an Open Source project and maybe i hit some cords in this talk. I know I struggle with this day in and day out.
You have to ask yourself if it's worth your time. Can you balance the demands of your users with little to no thanks, balance the demands of your corporate leaders, balance the loneliness of running a project by yourself? I can't answer these, you do. And hopefully I have given you some food for thought from this talk, and maybe soon you'll be on stage speaking of your experiances.
Thank you!
