My First Real Open Source Project
The following article is based on my experience in building RMWC: A React library wrapping Google’s official Material Web Components.
I’ve always been amazed with how much software is given away for free. From a consumer’s angle, the tech world always seems to be selling, tracking, and advertising. But for those of us who make the things? Free. Not just kind of free… like, totally free. It’s free to use, reuse, change, modify, distribute, scale, explode, explicate and use however you see fit. We would think it was crazy if mechanics just gave each other free car parts, but in tech it’s a way of life.
I’ve been contributing to Open Source Software(OSS) projects for a while now. I remember the first time I heard about Github. Back then the tagline was “Social coding” and it absolutely blew my mind that I could use and contribute someone else’s stuff. The first time I submitted a pull request to another code base and it was accepted, I felt like I had just performed some sort of wizardry. Over the next ten years, I would submit small PR’s, occasionally some large ones. When I found bugs I would open up issues, or post solutions I found. I even open sourced a few small utility type projects and was amazed that sometimes people actually used them.
Code Switching
When I made a move from Angular to React in the past year (two OSS programming frameworks), I had to find a new set of tools. Any developer proficient in a language or framework has a long list of libraries they use to get stuff done. I was at an immediate disadvantage as I scoured the web looking for the things people use most. I was looking for a user interface library (read: buttons, menus, toggles, etc) that implemented Google’s now ubiquitous Material Design language. The good news is, there were lots of them for React!
I started a new project and jumped into using what appeared to be the most popular and supported one, Material UI. I got to work on building my app for the next few weeks. It was all good until I pulled it up on my iPhone and the app just crashed. I started digging in and after several days of beating my head against the keyboard, I realized Material UI had performance issues that couldn’t be mitigated. I sighed, and found another widely supported one called React Toolbox. Turns out changing the way things look in React Toolbox was a notorious pain. So I tried a third… a fourth… With respect, all of them were incredible tools with lots of utility and I’m glad they exist, major props to the people maintaining them. The Designer in me saw the places that were missed on the Material Spec, the incorrect rounding of corners, the incorrect use of ripples. Little details like that are important to me.
Wrap it in a Bow
I was getting frustrated when I stumbled across a little gem. Turns out Google had noticed the many Material Design implementations on the web and decided to make and support their own library! I was really excited about the prospect of a Google maintained project as I could ensure it was a bare bones implementation of Material Design. I quickly searched for a React version of it but all I found were a couple of half implemented ones that I couldn’t use for various reasons. After weeks wasted on finding a workable UI library, I decided it was time to build my own.
My goal wasn’t to build this thing from scratch: I was going to use Google’s actual code and styling and just “wrap” it all in React. It would be less for me to maintain, and it would constantly be improved by a team and Google.
This is gonna be easy
…said the very wrong me from 3 months ago.
Hard Lessons, Good Lessons
I’ll spare you the details of the ungodly amount of work that went into building it but I’ll do my best to summarize some key things I learned.
Release Early
Find the minimum you can survive with and get it out there and published. Until someone can easily install your library, they’re not going to use it. The moment someone else can start using it, new bugs and use cases will start popping up.
Engage the Community
Take issues people file seriously. Find out what’s working for them and what’s not. Encourage them to contribute and collaborate with them. You can’t built it all on your own, and even if you could it’s not fun to. I was genuinely shocked the first time I saw someone else answering questions without me ever intervening. And nothing feels better than someone submitting a fix for an issue you didn’t even know was there.
Update Regularly
I might have done this too often considering there were 6 alphas, 10 betas, and 13 release candidates… When someone runs into an issue with a library they’re generally stuck until a fix can be released. Nothing is worse than finding out that 100 other people are having the same problem, but the issue has been open for a year.
Eat your own $%#@
Dogfooding is a necessity. You’ll find issues, learn what works well, and most of all it gives you the drive to keep improving it. After having multiple apps built on this library, I’ve been able to improve it dramatically while enlisting the help of a growing group of regular collaborators.
A V1 Release
So today I released the first major version. There are no awards for it. It won’t make me any money. It will continue to take time and effort as things keep changing and evolving on the web at break neck speed. Its cost me 100+ hours of my free time… but really, I consider it a small price to pay. After all, I’ve saved thousands of man years with all of the great free software built on the backs of people much smarter than myself, the least I can do is try to contribute something of my own.
Oh, and if you’re a dev reading this, next time you’re about to post an angry rant about how library X doesn’t do Y, I politely challenge you to try to make something of your own ;).
RMWC Src: https://github.com/jamesmfriedman/rmwc
RMWC Docs: https://jamesmfriedman.github.io/rmwc/
Me: https://jamesmfriedman.com/