According to Wikipedia:
Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose. Open-source software may be developed in a collaborative public manner.
The open-source phenomenon has become very relevant in the industry nowadays. I once read a book that described open-source as a social phenomenon since people from all over the world agreed on something and delivered software towards some shared goals and aligned with some established principles. The whole book was about analyzing this phenomenon, trying to understand why people start open-sourcing in the first place, how the interactions happen when there’s code in between, and how the outcome can be so powerful as to change standards in the industry and get huge corporations to use that software. I find it very fascinating when I think about Ruby on Rails
. Do you know how many startups and companies are running their business with software depending on open-source software (OSS)?
Quite a lot.
Being open is something seen as something good nowadays. If a company does open-source, it’s a company where a lot of developers would like to work. Are companies doing open-source because they really believe in what being open means, or because they just want to look attractive?
That’s a question that would require a deeper analysis on a per-company basis. Companies that have been traditionally closed, like Apple
, or Microsoft
have slightly shifted towards being more open. We can see programming languages like Swift
, or IDEs like Visual Studio Code
being developed in the open. Who would have imagined a few years ago that Apple would open-source programming languages or foundation frameworks?
Open-sourcing from a company is not easy though. The companies that do open-source they usually share a small piece of software that is used internally by any of their products. Those companies might have some legal and security process to ensure that the code that is shared doesn’t contain any business-critical information.
Our common mistake when we try to do open-source in a company is thinking that it’ll be as if we were sharing it from our personal GitHub account. The truth is that it’s not, and there are some other business factors that need to be kept in mind.
Moreover, open-source software is not a software that you make open, and then expect it to be self-maintained. Companies need to assume the costs of maintaining the software that they open-source, and not many companies are willing to do so because there are other important things where developers can invest their time on. They partially embrace open-source but forget about the most important part, maintaining it.
I think a key piece of working on open-source software is having a certain level of commitment without expecting anything in return. You don’t need to invest all your energy and time on it, but a few of it.
On the other side, developers are also doing more open-source from their personal accounts nowadays. In fact, I do a lot of this one, from either my account or an organization that I create to cluster repositories that have something in common. I like sharing my learnings and the tools that I work on to overcome the issues that I face as a developer. I don’t see the reason why I should do it in private. I get a lot of contributions from people and cool ideas that we end up implementing. Furthermore, you can include all those projects as part of your portfolio, and prove in your future interviews that you have experience, not only with the programming language but in designing APIs, doing versioning, automating tasks, continuous integration… If had to give a useful tip to developers starting their career it would be: share your tools and your learnings, connect to other developers and don’t be afraid of doing it. This fast-moving industry is very competitive, but there’re always people willing to help and listen to you.
Doing open-source has some pitfalls that are worth mentioning. The first one is that you need time. This is probably what developers find the most difficult when it comes to working on an open-source project. I don’t have time! In my experience, after working 8 hours every day, I have no energy to keep coding, nor do I want. I want to go for a walk, meet friends, read a book, but not keep coding. If you have kids, things get even more complicated. In my opinion, companies should give their employees time for this sort of things, either open-source or any other thing they are interested in learning. Working for a company shouldn’t prevent you from keep growing professionally. Another challenge is that you need a strong personality. The majority of the developers using your open-source project see you as someone who is producing something for them. When they have an issue, or the project doesn’t help them to solve all their use cases, they come to your project and use a very straight language like: “this doesn’t work”, “fix it”, “I’m disappointed”. The first time you get those messages it’s very tough, you don’t expect such interaction, especially when it comes from other developers, but the reality is like that. I’m learning to process those inputs, and prioritize them as they arrive. I usually take some time to reflect on the input, and if it’s very straight, I also take some time to think about the answer. I’m also learning to say no when there’s let’s say a proposal, that doesn’t align with the goal of the project. I used to say yes to everything, and by doing that, you end up with a project that solves everyone’s needs.
We can see an analogy with user-facing products, like Facebook. Since they want to do a lot of things from their platform, second-hand market, event planning, messaging, they ended up (in my opinion) with a very complex product, loosing their focus.
In my opinion, the integration between dependency managers and Git is broken since it’s designed to work in only one direction. You can use those tools to fetch open-source dependencies, and use them in your projects, but what if you want to commit something back? What if you found a bug and you want to propose a fix to the source repository? The process is very tedious:
- Fork the repository.
- Clone the repository.
- Add your changes and test them.
- Push your changes.
- Open a PR on the source repository.
- Wait for the PR to be merged.
- Update your code to point to a commit, or wait for the tool to be versioned.
By improving the other direction they’d remove a big barrier that many developers find to contribute back to the open-source projects. In the past, I used to workaround issues from my project, using a very hacky code, to avoid the tedious process that I mentioned before. Does it sound familiar to you 🙃?
Finishing up my thoughts on open-sourcing, what I like the most about all of this is connecting to people via open-source. You find a lot of developers that have similar use cases, and that are willing to help and move the projects forward. You get to know them and collaborate with them, making them feel part of the project. This is the most challenging and rewarding part of doing open-source. To make it possible, I try to make the projects as inclusive as possible, inviting everyone, no matter their experience to participate, setting myself apart from the project using GitHub organizations, and creating a Slack group where everyone has a voice and can participate in open discussions.
What’s your experience doing open-source?
Have a great week,