5 Things We Love About Writing Open source Code
5 Reasons why your open source projects on GitHub are probably the best code you’ll ever write, and how you can apply these principles to every day’s work.
We all know that fuzzy feeling when you grab that coffee on Friday night and turn on the screen, knowing you have nothing better to do but to invest the next 4 hours building your awesome GitHub project.
That feeling doesn’t always tingle on Monday morning though, does it? Well, It might be more up to us than we think.
Here are 5 things we can learn from the way we collaborate and work on our open source projects, which we can bring into our every day’s work.
1. Collaboration without politics
“ The big thing about distributed source control is that it makes one of the main issues with SCM’s go away — the politics around “who can make changes.”
Every developer can probably point to a moment in time when their bright or far-seeing idea was discarded simply because, well, people are people.
The beautiful idea that through effective distribution anyone can commit any idea or change to any project is one of the finest examples of collaboration in human history, not being limited by geography, nationality or rank.
Here’s where it gets more tricky: Git is amazing for collaborating together on a single project.
But, what happens when we need to collaborate and share code between different projects?
When it comes to collaboration within an organization, things tend to get even more complicated.
Usually, shared code comes in the form of packages and shared libraries, which in turn are bound and coupled to specific people and repos.
Let’s say you need to use a small package or a part of a shared library which exists in your organization, and is maintained by the infra-team, but you also need to make a small change to that library of package to fit a new project.
Your common option is to make a PR to the repo from which that package or library was published, and wait a few weeks with fingers crossed.
When the change you need is too context-specific, it makes no sense to update the whole package or library, and the only option would be to create a new repo and publish a new package. This workflow is limiting and discouraging.
This idea is one of the very reasons why Bit was created to improve and distribute the workflow around sharing code between projects as a team.
With Bit, components of code can be shared directly from any repo and developed from any other repo, while changes can be synced between them. This workflow works for anything from UI components to Node modules and even GraphQL API components.
2. A better degree of abstraction
One of the best things about building a GitHub project is that it’s often born out of an idea which comes from a very real every day’s life experience.
However, when you want to turn this idea into a new project, you also need to generalize it just enough so that it will be useful to other people.
While over-generalization should generally be avoided, thinking in modularity and reusability is also the key to better code sharing.
When you write code which is meant to be shared, you keep in mind two key questions: “will it solve my problem?” and “will other will benefit from using it?” When the answer to both is positive, you’re on the right path.
Here’s a quote I like by Google’s Addy Osmani.
“ If you’re building components to be shared with the community or even just your team, ask yourself if features in your API will be used by 90% of users. If so, it’s likely pretty core functionality and should stay. If a feature it going to be used by the 10%, it should probably be a separate component or module. Avoid code bloat. “
Bit’s distributed workflow also helps you change and evolve shared code from any project, so it can be easily modified to fit different use cases while changes can be easily synced across your codebase with universal control.
3. Discoverability is worth the effort
Open source code is usually better tested and documented, that’s a fact. Many arguments can be made as to why, but here’s what I think.
When you share a photo to Facebook, you usually don’t post a photo that looks bad, because you want other people to enjoy it.
I think that we better test and document OSS code because we want other people to find, use and enjoy it. We realize that docs, tests and examples help people understand, trust and use what we worked so hard to build.
Popular libraries like Material-UI invest a lot of time into maintaining a great documentation website with live rendered examples and docs. Still, when it comes to shared code, discoverability can be tricky even in the open source.
“ Discoverability is often cited as npm’s biggest flaw. Many blog posts — scratch that, entire websites — have been created to try and mitigate the difficulty of finding what you need on npm. “
— Rich Harris, rollup’s author
When working in an organization discoverability of shared code is an even more painful problem. Who’s to know what code was already written, how to find it, how to judge it’s quality and understand the use cases it handles?
One thing we did in Bit is to emphasize the discoverability of shared code through simple visualization of this critical information.
To make this process simpler, Bit does some of the heavy-lifting for you by presenting docs and examples parsed right from the source code, test results and even a live visualization playground for your shared UI components.
To monitor the code’d quality, components are tested in isolation using Bit’s component-environment and understanding of the code’s dependency graph, while results are provides per-components to judge the use cases it handles.
Here is an example of components shared from this project, and here is an example React component with improved discoverability.
“ By splitting out a component into something smaller, it’s generally easier to test and document. Keeping your component source DRY can help. “ — A. Osmani
4. Code evolves as we do
I like to think of the code we write as a living organism.
It’s built out of smaller components and units, it performs tasks using algorithms and it has to deal with a complicated and an ever-changing reality.
Just like all living things, code has to evolve to adapt. Git does this wonderfully for working on a single projects:
Anyone can clone the project and make the changes they want, anyone can PR the changes to the original project, anyone can create a better project. When two (or more) people merge branches, a new child is born.
But what happens when we share code between two projects? How is that code going to evolve?
The problem is, this “evolutionary” workflow is limited for cross-project collaboration, and especially within larger teams.
Bit’s philosophy is very similar to Git’s. Smaller components can be easily shared between projects and repos, evolved and changed from any of them to fit different environments while and merged to sync changes between repos.
Using Git + Bit we were able to share over 250 components between our Node.js microservices and our UI projects. We are able to organize and collaborate to improve the shared components of code from different projects, and sync changes between them with a single click of a button.
“ To improve is to change; to be perfect is to change often. “
— W. Churchill
5. Joy of creation
This might be the single most important point of them all: the joy of creation.
When we create a new open source project, we are able to create something new and share it with the world. This is exciting. It’s not that different from a pinter starting a new piece or a musician working on a new song.
I believe that imagination-driven creation is vital to innovation. We can’t create new things only by optimizing what’s already out there.
I also believe that creation is what turned the open source into one of the most innovative and advanced technology bases in the world, with projects ranging from React and Node.js to new ML and IOT libraries.
Lowering the barriers for creating and sharing code code means accelerating the way we move forward. This is also a keystone in the philosophy behind Bit, and why the project was built as and open source project on its own.You are welcome to use it, suggest feedback and contribute.
You are also welcome to comment and add your own thoughts on what you love about working on open source, and how it help make Monday morning feel just a little bit more like Friday night.
