I am Carolyn Van Slyck, a Senior Software Engineer at Microsoft, working remotely from the wilds of suburban Chicago. My passion is developer tools and building vibrant, inclusive communities around them. I've previously been a maintainer for Go's dep, and Kubernetes Service Catalog. I am also on the Kubernetes Code of Conduct Committee, an organizer for Women Who Go, and occasionally Write / Speak / Code.
Right now I am working on Porter, a CLI that implements the Cloud Native Application Bundle specification, CNAB. Porter is a cloud installer for your applications, packing up your application, the dependencies necessary to install it and the logic that handles deploying the application to your infrastructure while injecting any necessary configuration and credentials. Similar to what Docker did for running applications, Porter is the same for doing deployments.
I created Porter along with Jeremy Rickard last year in response to how confused we were by the CNAB spec! The CNAB specification is so unconstrained: a Dockerfile, entrypoint run script, and conventions to passing credentials and parameters. We didn't think that anyone would really understand bundles or take advantage of them properly without some building blocks. Porter gives you those building blocks and also a) doesn't require you to know that the CNAB spec even exists and b) makes the 80% case just work out-of-the-box and c) prioritizes developer experience above all else.
Porter's building blocks are called "mixins". For example one of the out-of-the-box mixins is for Helm and it handles a bunch of tasks that otherwise you would have to do yourself in a bash script:
We have grown sustainably, at a pace that we can manage considering how many maintainers we have (3). Porter never really was a project that got a lot of press or was something that Microsoft threw a lot of resources at. We were given space and time to develop our prototype in the open, anyone could see the code on GitHub and try out releases as we progressed. Once the CNAB specification got closer to 1.0 and finally hit 1.0 this September, Jeremy and I started going to conferences and encouraging people to start trying it out.
I honestly have no idea how to promote a new open source project! 😅 I have tweeted about it occasionally and blogged once. We created a #porter channel on the CNCF Slack and that has grown over time, right now we have 46 members. I care more about the quality of interactions which has been very high, with great suggestions from users, feedback on where things are rough, bug reports, and one of the few ways I can tell that anyone is using our stuff. I did a webinar for the CNCF that seemed to attract users to the project most effectively.
That said, we are all developers and don't have the interest or skills to measure users or growth. So I wouldn't even know how to quantify how much we have grown. I can say that 6 months ago we had less than 10 users and I knew all their names. Now I regularly have people post in our #porter channel who I have no idea who they are or how they learned about Porter. So I'm pretty happy with how it has grown from something only people in the know use, to have worked its way outside of our little bubble.
I also put out tweets and slack messages around the same time encouraging people to contribute which I have been extremely happy with. So far we have had many repeat contributors and a few contributors who are on their way to becoming maintainers.
I manage my own workload. But it's an open-source project. People don't work for me, I don't tell them what to work on. What I can do is set expectations and contracts between the community and the maintainers. So before we put out the welcome mat for external contributors, I work hard to make expectations very clear on what interactions should look like when working on Porter, and how they can work their way up the contribution ladder to become a maintainer. Our reviewing guide also helps reviewers understand what's normal and enforce boundaries. My goal is to welcome new contributors while also protecting our existing contributors.
I also spell out in our roadmap that "Porter is an open-source project and things get done as quickly as we have motivated contributors working on features that interest them". Essentially people will work on what they are interested in, and I embrace that instead of fighting it. I regularly go through our GitHub issues to ensure that issues are clearly labeled. For example
good first issue are ones that have enough information in the issue that someone new to the project could attempt on the weekend without having to ask someone for help. Others like
hmm 🛑🤔 mean that we need to collectively discuss that issue further before anyone picks it up and starts working on it. There are lots of areas for people to work on and issues are generally filled out enough that people can pick and choose where they want to invest their time.
The maintainers meet once a week on Zoom to share what they are working on, update that roadmap if it's out of date, discuss tricky PRs, make sure to welcome new contributors or, if we are ready, promote someone to maintainer.
I think that Porter is the best tool for working with Cloud Native Application Bundles and I don't want anything to get in the way of people using it. My goal for Porter is to become a community-owned tool that lives in the CNCF. We have worked really hard to make Porter community-friendly. Nothing about Porter is specific to Microsoft. It runs on any cloud, or on that computer under your desk. Anyone can create a mixin and have it be a first-class citizen just the same as the mixins written by the maintainers. Anyone can work their way up the community ladder to become a maintainer, it's not restricted by what company you work for.
I'd like to see Porter build up more maintainers and have its ecosystem thrive. Ideally, it shouldn't rely on any one person, myself included, to be healthy and continue.
I have been working in open source since 2000! 😂 I gave a talk at Gopherpalooza last year about my journey from rando open source to deciding to work mainly in open source communities. At this point, I am dedicated to open source because I enjoy building connections with people that are stronger than the companies that we work for. People switch companies all the time. When working on OSS, such as Kubernetes, someone can go from one company to another and keep working on the same project with me, stay in the same larger community. Especially since I am remote and have been since 2012, maintaining connections in my industry, being visible and having people know what I do, is incredibly helpful. I can go to a conference and run into people who I worked with 18 months ago and catch right up where we left off. This fills me up both personally and professionally.
I also really enjoy the opportunities it affords me to pay it forward. I am never going to be a manager, so I don't get any chances to say "Let's hire this person", or "She would be great leading this project". But as a lead on an open source project, I get to do this. I meet people online who want to get into Go, learn Kubernetes, do more coding outside of work, or try open source, etc. And I get to say "Come play with me!" "Yass, girl, I have so many issues, pick your fave and we can code together 🚀". They do the hard work, they show up, and it's not always comfortable for them to be the odd one out. But I can't describe how it makes me feel to be able to clear paths to even give them that chance and make sure that my project is one of the best ones for them to invest their time in. I've made friends and seen people move on to great jobs after building experience in an open source community.
My advice for other maintainers could literally fill a book. 😂 I would start with understanding why your project is open source and what your goal is for your project. Then refer back to that regularly to make sure that you are meeting your own goals, instead of doing what you think others expect of you. It's okay to have a personal project just for you and not support strangers on the internet.
If your goal is to build a positive sustainable community, I suggest finding one first, lurk, read their documentation, watch how the maintainers interact with the community and then participate yourself. If you've never experienced one yourself first-hand, it is incredibly difficult to create one without good role models to follow.
Then make it a regular part of your community's process and culture to talk openly about how well it is working and what can be improved. What you come up with on day one isn't going to work on day 100, or year 2. Your energy and motivation on day 1 won't be the same in year 2 for that matter.
Good luck and make sure to take care of your maintainers and yourselves! 💖