What I learned working on Knative open source for 4 months

These past 4 months, I was blessed to have a internship in DevOps. This internship was special because I had to advise the company on how to use and implement a serverless infrastructure. My journey brought me to Knative, an open source project that is just 1 year old. Knative is a set of powerful tools to build, serve and react to events in a serverless infrastructure based on Kubernetes. A lot of companies work with Knative. The project is mostly back by Google, IBM, Red Hat, Pivotal, and more.

Starting out, I did not have experience in DevOps. The only thing I knew was Docker, of which I would later discover that I still had much to learn about. Also, as with every new Google backed open source project, everything is built in Go and I knew nothing about Go! With this frame of reference established, you can understand that I was a total greenhorn in the field. The following details what I learned going from a beginner to OK.

The community love to help

This is something that I did not expect. If you are true to yourself and say up front that your knowledge is limited on a subject, people take their time to help you. However, you have to do your homework first by reading deeply into the documentation and using that information to correctly present the problem you are having in the right context.

For example, I was working on a Jenkins build that was using ko to build and push code in Go, but I was having a problem pushing to my Docker repository. So, I checked the error log and pulled the code on GitHub to understand where the problem was in my code’s flow. After some time, I found where was the issue might be, but I did not understand its potential impact. Thus, I reached out to the main team of ko on Slack. After lengthy discussions and testing over 2 days, I tried to fix the bug in the code to no avail. I eventually found out that ko was using another project to push images called crane. Crane was the problem. With that information, I finally opened an issue on go-containerregistry repository on Github, where the project is. And this is not the only example that you can find. Open source community is truly helpful.

You have to know why you do every line of code

The best contribution that you can do in an open source project is a contribution to the code. When you add code, you need to know why you are adding it, for each line. This is even more true for removing code. The community is there to help you to write the best code possible, but again you have to do your homework. If you do something hacky or unintuitive in your code, the best practice is to add comments to explain what that code does. In an open source project, it is even more important to have readable and self-documenting codebase. You can never have too many comments explaining your code. For example, one of my pull requests (PR) has upwards of 40 comments on it and, at the time of writing this article, has been open for 26 days. Usually, PRs stay open for about 1 month. This gives the community enough time to review every bit of your code. There, they can ask questions about every detail. Things you thought were obvious could be complicated to another contributor. This process also allows the community to find edge cases that you, the author, never considered. This ensures that every code contribution is of the utmost quality and is built to last once the review ends. That’s the beauty of open source!

Someone can work on the same project as you

When working with open source, you work with people all around the world, in every time zone. For example, I worked on a project with a worker from IBM China. The only time we could chat was at 10 pm for me, because of the time difference. Furthermore, she was working when I was sleeping and vice versa, so the project was moving along very fast. In about a week, we were preparing to do an official PR.

But, as we were preparing our PR, someone beat us to it and ended up opening a PR for the same problem on the same project we had been working on. Fortunately, the time we put into this issue was not wasted because we ended up making several contributions to this PR. But this illustrates the pros and cons of having a multitude of people working on the same project, at the same time, and in different time zone.


You can work in parallel as you with any regular 9 to 5 work day with your team, but you can also work in series, back to back, with other people in opposite time zone as yours. That makes a project go very fast if everyone knows what there are doing.


If someone needs a feature that is not in the project, they will maybe try to build it. But if this person does not open an Issue to say that I will work on this new feature, maybe someone will work on the same things at the same time, which results in wasted time for the community. That said, the opposite is also true. Before trying to contribute something to an open source project, you should ask the community if there is a need for it. You should also check if the is an issue open for your feature.

Github is very more powerful than you think

Most people use GitHub to host code, maybe opening a PR here or there, but GitHub has so most more to offer to encourage collaboration. For Knative, we use:

  • GitHub Issues to do feature request and bug report
  • GitHub PR to review massively the code of other
  • GitHub Fork to be able to create copies of the code in user repos
  • GitHub Projects to follow the progress and to assign a task to people
  • There also your Grafana with GitHub Webhook
  • Slack to talk with other contributors, ask for help, and help others

Big open source projects often also have an organization composed of the project’s top contributors (around 9 people normally). Their role is to vote on key issues and representing the open source project at conferences. Finally, there is usually a weekly meeting that you can attend to talk about the project roadmap, new features, demos, and more.


So, the next time that you will start a new project, think about if you can make it open source. That way, you can help more people and more people can help you. I think open source is the best organizational structure that we can use to guide the world to a better future, together.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store