Getting paid to do Open Source.
This article should have been written a long time ago but as it so happens, time flies when you are having fun. My former colleague John Sundell did quiet a roadshow last year (2017), and he kept getting questions how we get to do open source and get paid for it. It is time to reveal the secret sauce. It might not be as secretive as you think.
Open Source is something that I strongly care about, in fact, I talked about this at the 2017 Mobil Era.
How it all got started
Open source at Hyper got started before I joined the company. It was based on the simple premise that if we were to use open source, we should also contribute back, either by helping out on existing projects or creating new open source under the Hyper umbrella.
Fear of doing Open Source
I’m going to let you in on a little secret when I applied for a position at Hyper, I had never made an iOS application, not properly anyway. Heck, I didn’t even know about dequeuing when using table views, let alone had I ever publish any code publicly. I entered an entirely new domain. I did, however, have amateur experience with OS X development. For weeks I was terrified that I would be labeled as a fraud and kicked out of the company faster than a saloon door retracts after entering. Luckily for me, Hyper is a super great place to work, with collaborative and knowledge sharing at its core. I quickly learned what I had to to do my job correctly but I still had one big fear that openly clashed with the companies core value and that was the fear of doing open source. I couldn’t wrap my head around what that would bring to the table, I only saw it as yet another way of uncovering me as a snake-oil salesman. The front-runners for doing open source was the web team, they were heavily invested in Ruby on Rails and produced great gems that they naturally shared with their community. It just so happens that the first open source software that I released for Hyper was a ruby gem called singleton-rails, my co-worker Tim Kurvers did the heavy lifting, I more or less just pushed it to rubygems.org. Even under these circumstances, I was still terrified to have my name on something out in the open. This was back in 2014, and “past-me” was petrified.
If I could reassure “past-me,” I would hug him, tell him that everything is gonna be okay. Explain that open source is nothing to fear but something to embrace, good times are ahead. I would then proceed to remove his tinfoil hat and compliment him on his hair.
“The universe does not revolve around you!” — Future me giving advice to past me
I know a lot of people feel scared about doing this, and who can blame them when stuff like this appears on Twitter.
I know that the author meant no harm with the tweet, but it quickly escalated into an online mockery. I am even guilty of cracking a joke about it on Slack, saying that it hurt my OCD for the lack of sorting. But even if my comment was private, I should have known better. If this indeed did bother me, I could have done a PR to correct the thing, not make fun of other peoples source code. I sure wouldn’t want anyone doing that to me, and if they did find any shenanigans in my code, I’d love a PR to address it.
How to get started
During the transition between Objective-C and Swift, our team landed one of the largest projects to date. One obvious question came to light, what language do we pick. We went many rounds on this, bouncing back and forwards with different arguments popping up, being invalidated and corrected. Eventually, we landed on Swift; this gave us a unique position within the community to write pure Swift frameworks, this was a real hot topic at the time. We were four developers working on the project which led to the decision to split the project up into different features and making micro teams for each part of the application. Each feature got their own specifications, we collectively went through all of them and unanimously decided which parts could be extracted out into a framework. Two main reasons often tipped the scale, the first one was the results of the question “Could we leverage from this feature in a different application,” the other being: “Would it speed up development if this was its own component.”
To shed some light on why the second question was deemed essential, because of the team and applications structure, we could now more easily share parts of the application without giving clear ownership to one of the micro teams. It increased productivity as these components could be tested in isolation, we avoided a lot of merge conflicts as the framework was imported outside of the applications own structure. One huge advantage of the framework approach also meant that we couldn’t have any strong ties to any parts of the application as they simply cannot exist when dealing with frameworks. This forced us to think through the public APIs thoroughly. This is where we started to become framework developers.
You might not remember, or might want to forget but in the early stages of Swift, the language struggled with compile times. This severely crippled our development speed. This is where “framework-driven development” really helped. It reduced the need to build the host application when doing development we would instead build an example application that used the feature in isolation. When the new feature, bug fix or refactoring was done, only then would be fire up the host application to check the final result in the end product. This is not as big of a deal these days but the approach can still be valuable for larger projects.
Branding Open Source
To achieve the full potential of Open Source driven-development, you also want other people to use your frameworks. This means that you have to sell it, make it relevant to people. Think of the README as the CV for your framework, what are the most important things to mention, you should probably have that appear at the top.
“No one wants a pig in a poke.”
Add “Getting started …” guides and link to those in the README, this minimizes the chance of having people abandon you at first glance, people care about public APIs and the overall usage of a framework. This can help win over people that assign risk with adding frameworks to a project, simply by just showing it first hand what it solves and how it looks.
No one wants a pig in a poke.
It is also important to look good to stand out in a crowd. We achieved this by making header images and icons for our frameworks. This shows that you put a little bit of extra effort besides just punching out the awesome source code. From a remembrance perspective, it is easier for people to remember something that they saw then something they read.
To get picked up in the first place, start adding your frameworks to awesome lists, contact people running newsletters or blogs, etc. Heck, write your own blog posts or start a company engineering blog.
Tweet about your problems and follow up with how you eventually solve the issues, chances are that people run into the same issues as you but in different contexts.
With a bit of luck and the help of the community, you might get featured on sites like raywenderlich.com.
Open Source is good for business
There are three different perspectives that you should consider to deem something to be a good business decision.
First is, you the developer. Let’s say that you work for a company that makes first-class applications that are both stellar both on the outside and inside. You pour your heart into beginning the best version of yourself while working for this company (like we all do). After two years you find out that you want to continue elsewhere, because of reasons that are your own. You interview for your next position at your dream company, during the interview process they ask what you have been up to the last three years and because the new company is industry leading they do their homework. They ask for source code, something that you are proud to show off.
“Open Source is lucrative for your portfolio.”
The catch with your previous company is that they made things white-label, plus they did not invest or even care about open source software in general. It hardly seems fair now does it? After all, you poured your heart and soul into making stellar apps, but in the end, you have very little to verify your competence. This is where open source is lucrative for your portfolio. Even if all the applications that you make are white-label, you can still share what happens behind the curtain. For the person doing the hiring, this can increase risk involved with getting new people on board as they can get a firsthand look at what you are capable of.
Also, you shouldn’t overlook how rewarding it is to know that you helped out in the community.
The second perspective is the company that you work for. If you apply the same scenario as for the developer, the companies customers demand white labeling, then how can we build a portfolio that validates that we can do what we say that we do. Again, this is where open source can help on multiple levels. If your development team shares and are active within the community, it helps both with visibility and as validation. It shows that you have the right people for the job. Features can be displayed without the app context, just like when it comes to testing a modular part of a system, it can be done in isolation, without losing its value.
This can also strengthen your position when it comes to recruitment as you now have a window for people to peek through before joining, they can get familiar with how the code is produced at your company. It can tip the scale for people uncertain if they are making the right decision, it can motivate people that they will be able to contribute to open source while at work and it can even get people to join the team when in fact they weren’t even looking for a new position.
The third perspective is the customers, the people that pay. They all expect the best as they want their apps to climb the App Store / Google Play ladder while looking at their retention rate skyrocket. To ensure that the user experience is up to par, you need to battle test your toolset. This can be done internally with closed source frameworks but to up your chances by getting help from the rest of the community to add new features and squash the bugs.
So as you can see, this is a win, win, win.
“Var lite, lite snällare än du måste vara … “
When doing open source, we have found that being nice never hurt anyone. Even if you disagree with an author of a PR or if an issue might try to push your repository into a different direction than you initially intended. It is always super good to be nice, be polite and point out things that you like. Don’t get me wrong, telling someone that you disagree is okay; you should just point it out and do it in a manner that is nice. I would even go as far as to say, try to be just a bit nicer than you have to. If everyone followed this mantra, then I’m quite sure that we wouldn’t stumble into to that situation that occurred with Dash iOS becoming open source.
For every negative thing that you find, try to find two positive to even it out.
If you are a part of a community, you share a collective responsibility for the culture of that community. This goes both ways; when contributing to other peoples craft, you should be equally nice.
And remember, don’t act friendly as a part of your branding, be nice because being nice is nice. Otherwise, you will be the pig in the poke.
I highly recommend Orta Therox talk “Nice in Open Source” — https://news.realm.io/news/altconf-orta-therox-being-nice-in-open-source/
Give credit where credit is due
This should be a given, but I’ve seen numerous occasions where people simply forget to do this. If other people inspire you, use parts of their implementations, why not contact them and commend them for what a fantastic job they are doing and that they should keep doing it.
There is this simple rule for people who are doing things wrong, how would you expect them to change if you never tell them. Flip that rule on its head and shake it a bit, if you want people to keep being awesome, be sure to tell them that they are on the right path to continue being awesome. This can make a person’s day; it certainly has for us.
One way to make this stick is to add people who helped you to the README, so that its on display for anyone who looks at your repositories. This will not discredit you if anything it would just point out that you are awesome for giving credit where it is deserved. We are firm believers that perfection comes from iteration, if that means someone else is iterating on the thing you want to perfect, this could help to inspire you further even if you were the initial author.
And while we are on the topic of giving credit where credit is due. I’d like to give out some honorable mentions to two extraordinary gentlemen that became key pillars for making this open source story into an epic adventure.
Elvis Nunèz, he got me hired at Hyper and is the real reason we were a big success back in the day when we wrote Objective-C on a day to day basis. He is the mastermind behind such frameworks as Form and Sync. He put in the extra effort to get us off the tarmac before we even knew we could fly.
The second person I’d like to mention is Ramon Gilabert. He pretty much took over for Elvis when his adventures continued elsewhere. Ramon continued the legacy with grace and perfection, producing tremendously popular and gorgeous open source libraries such as Whisper and ImagePicker.
Kill your darlings
Nothing tastes quite as sour as when something goes out of style, or to use the industry term, becomes deprecated. All that hard work, and for what? That might be the initial reaction, but here is a small thought experiment you that might cheer you up. How many applications has your framework outlived? How many people has it helped? Even if it only helped you, I would still grant it as a success. Putting up the closed sign does not indicate failure, it just means that the winds have shifted and you probably have a replacement tool already. This is a natural part of any frameworks lifecycle, things change, things go out of style, and frameworks get deprecated.
But cleaning the slate and removing everything is not your only option.
You can mark the repository as deprecated, take on collaborators or seek new maintainers. There might be people who love what you have done so far and still feel that there is life left in the framework.
One thing is for sure, don’t give people the wrong impression by keeping it around just for appearances.
Don’t dismiss, submit a fix
Even if we still do a lot of our own frameworks, we do use other peoples open source, and with good reason. Most of the time there is no valid reason to re-invent the wheel. But if you do find yourself being dissatisfied with a third-party framework, don’t dismiss the framework straight away. Try to help the authors of the framework to fix or in other ways improve the framework.
This is what you would like people to do when it comes to your frameworks, am I right?
The worst thing that could happen is that they won’t accept your changes because of X reason. That doesn’t mean that your efforts are in vain, you still have your patched fork that satisfies your needs. So please don’t dismiss before trying to fix what you need, going down this route helps both you, the author and the rest of the community. Let’s take our collective responsibility and build great things together.
Working with your hobby
I used to play a lot of video games, everything from Nintendo Classic, obscure arcade fighters that were never released outside of Japan to World of Warcraft. This took a screeching hold when I became a father. The two were not directly related; there had been a downward spiral from when I had my eyes opened and started doing open source outside of work. Some of you might see this as sad; other agree that games are just procrastinating. I would disagree with both; I’d say that I’ve just switched one hobby for another. The upside for me is that I can now do what I enjoy at work and get paid for it. Sure, call me weird, but I thoroughly enjoy making frameworks, diving into the nitty-gritty details of what I’m trying to wrap up in a neat and tidy abstraction.
“Anything worth doing, is worth doing right.” — Hunter S Thompson
This is the way I learn; it has always been this way. I’m not saying that you have to do this to be able to either develop or maintain open source libraries. But if you do decide to implement an open source-centric workflow in your company, be sure to plan ahead. We didn’t start out getting paid to do open source; it happened because people went the extra mile. A lot of hard work and a lot of hours have been poured into creating the open source tool belt that Hyper now respectfully wears. You can do the same, just don’t expect miracles overnight.
With that said, I cannot underline the importance of this process not becoming overwhelming and swallow you whole. It is supposed to be inspiring collaborative and fun. Anything worth doing, is worth doing right, that includes you enjoying what you do. If the lines between work and hobby are starting to blur, it is probably a good time to take a break.
Pros and cons
After all this pros and praise with doing open source, it is not for everyone. You would have to change the way you work to develop and maintain it. Jamming it in with brute force will hurt more than it improves things.
“Just because Open Source is free doesn’t mean that it doesn’t come at a cost.”
With every framework comes maintenance. What this means is that to continuously develop something you also need to take into account that other developers also have dependencies to your work. You need to consider strictly following semantic versioning to not break everyone else’s code. This also affects how you reason about new features, when to release new versions, review pull requests and responding to issues. We also need to update the framework to support the latest versions of the language they are written in. Just because Open Source is free doesn’t mean that it doesn’t come at a cost.
From our perspective, the pros strongly outweigh the cons. And to be 100% honest, at the time or writing; we haven’t gotten everything figured out.
We still struggle with having long response times when it comes to PR’s and responding to issues.
To tackle this head on, we are trying out numerous action points. The latest one is to have an Open Source goalie. Someone is responsible for responding and doing initial reviewing. This role would rotate every week which makes it into a collaborative effort. We also do a fair share of Open Source in our spare time, and that is okay for us because we are not forced to, we like to.
So don’t jump on the bandwagon just because we say that it’s awesome and works for us. Analyze your landscape, it might differ from ours, and your pros and cons list might end up looking completely different. Do yourself a favor and at least consider it, it might be worth the cost.
Summary
- Don’t act nice, BE nice because being nice is nice.
- Give credit where credit is due.
- Open Source is good for you, your company and your customers.
- Have fun.
- … and eat your vegetables.
