My experience leading an Open Source project

My job is to design and develop software. My hobby is to design and develop software. You know, the kind of unpopular guy in the company parties: while people would be talking about anything else, I’d be talking about Linux kernel.

So, in my free time, I help some open source projects or I make software to help in my productivity. Not to mention my contribution to game console emulators and related stuff, but you can have an idea visiting my GitHub account.

With this in mind, let me start now the story: back in 2013, I’ve joined the Groupon project, as a contractor, and they were using Campfire as chat/collaboration tool (which now it’s embedded on BaseCamp).

Campfire had web, Windows and Mac clients, but no official Linux client. But there was an open source one, Snakefire.

Campfire client

Snakefire was a python based client, consuming the Campfire API. I tried to find a Ubuntu package for it, and realized they were trying to build one, but no success. So, I’ve decided to help, and learned how to proper build a Debian/Ubuntu package and how to setup a repository for it.

Other interesting point while working on Skafire I’ve noticed is that the chat panel (the one displaying all the conversation) was made by a HTML engine rendering the chat logs using standard HTML/CSS/JS.

I just realized that, if I was the author and had few time to develop a client like that, probably I’d use a HTML engine container rendering the web version of the tool, instead of develop the entire client program consuming the API.

Of course, today this is a popular approach (release a Electron program just wrapping the web version), but on that time it was not a known option.

Slack

Internally my company was using HipChat, but then in the beginning of 2015, they’ve decided to ditch HipChat in favor of Slack as internal chat/collaboration tool.

HipChat client

HipChat had a great Linux client, offering same features in all platforms. But Slack started offering only a web and Mac clients (yeap, not even Windows).

Slack client: only for Mac!

The web version had some downsides: it’s a pain have a browser tab for each project; it’s hard to find each chat tab when your browser has 20 or more tabs opened at the same time; it’s not clear when you missed a message addressed for you.

I’ve sent an email to them, asking for a Linux client, and the answer was:

We don't have an Linux-ready app at the moment, but we're likely to have one down the road

Then, I asked if I could help in anyway to develop an open source Linux client, and the answer was that they have “an in-house development team so I don’t think so”.

No API

So, during the weekend I’ve started to develop a simple client for it. As Slack has no messaging API, I’ve applied the idea that I got while working with Campfire: I’ve made a simple desktop container running the web version (my first python and first Qt program!).

I’ve inspected their JavaScript code and made my simple client interact with it, displaying desktop native notifications about new messages, displaying the number of unread direct messages and launcher icon wobbling on new messages.

I’ve sent an email to Slack, mentioning my open source client, and they asked me to not use their icon, not use their name and make clear was not an official client. Which is fair, as all of their artistic work is a copyrighted material.

So, I given it an ugly name, an ugly icon, created an Ubuntu package/installer and published my work on GitHub as ScudCloud:

Got popular

I’ve sent an request to AlternativeTo to insert my open source client as an alternative to Slack on Linux, which was accepted.

Probably I’ve answered people on StackOverflow citing it too (yeap, I spent some time helping people there).

I got some mention here and there, but after I got an mention on MakeUseOf, people really started to use my client!

The bounty for that: I was helping others with my open source client! And of course, I was almost forgetting about it: I got thousands of new issues on GitHub!

Aside a ton of bugs, several improvement requests: clipboard image copy/paste support, keyboard shortcuts, HiDPI support, custom themes, spell checking, enterprise authentication with google, other Linux distros (Fedora/RedHat/Arch) installers, chat logging, etc.

I started to implement some in my free time, but the email notifications started to increase a lot!

And the worst part for me: as Slack has no official API, they kept changing their internal JavaScript in daily basis. So, every new morning, several new emails asking me to fix the software that got broken while I was sleeping.

Not only that: some people reporting issues was really unfriendly, sometimes even aggressive!

And, well, while I tend to be super professional managing my free time, this time I got blind: initially I was super excited. You know: love make us do stupid things!

So, brief recap. How it started: I was used to spend 1 hour at my morning, before my work shift, to work in some hobby projects. Usually something that would help me, boosting my productivity. And I’ve made that: created a working Slack client for Linux in a couple of hours, so I don’t need more to use the web version.

How it ended: I was spending all my free time on it. Initially due the excitement, later imagining that I’d be able to polish the program enough, so the volume of issues will decrease.

Then, basically, my day was just coding for my job (which I love it), then work on ScudCloud, then sleep.

I code since my 11, and that was the first time in my entire life that I got tired of working in a software.

Handling the burnout

I reached a point that I could not even look at the purple ScudCloud icon. Really!

That was the time I’ve realized that I was close to have a burnout.

This would end in 2 ways: the software got stuck and probably die (although by the open source nature, probably someone would take the code and continue, when the software is important enough); or I could try to manage this situation in a more professional way.

So I’ve decided to apply a mix of obvious professional projects tips + some open source benefits. Let me talk about them.

1. Organize notifications

As I work as a contractor, I keep jumping between different projects. So, a lot of company emails + GitHub notifications for a lot of projects keep reaching my inbox.

I handle that redirecting all email accounts to my personal one and I configure Gmail filters to move incoming emails to related project folders. All under a [Work] folder.

So, I’ve decided apply the same for open source projects with a lot of notifications: I’ve created a [FOSS] folder, and created sub-folders for each open source project that have a high volume of new emails arriving.

With that, I can simple collapse the [FOSS] folder, and basically forget about them until I had the time for them.

I know this is a simple (and obvious) tip, but that make my life A WAY BETTER!

2. Limit your time

I was spending all my free time with a project that, while was helping others, was not making money for me. I was spending time on it that was supposed to be life quality time: time with family, time to go outside, etc.

Again: if I really reach the burnout point, I’ll abandon the project, so no more benefit for anyone.

I got back to roots: work 1 hour in the morning in any hobby project. This will include the time for ScudCloud. Sometimes fix a simple bug before go to bed.

3. List the priority

This is obvious: limiting my time, to survive, I’d be not able to fix all issues or implement all feature requests.

So I’ve decided that my priority on issues would be to keep the program working, as the cat and mouse game (Slack changing their JavaScript code daily) was basically the hardest one.

4. Scope the project

You’ll need not only list your priority on the list of issues and feature requests, but you’ll need to think what exactly is your goal with your project.

Like I’ve said, people started to ask me to implement features that Slack was not offering, like additional themes.

I answer them clearly: sorry, but my goal is to keep ScudCloud as a simple container for Slack (while, of course, offering good integration with the Linux desktop).

So, if you want more features on Slack itself, ask them.

5. Let the community help

I started to be more clear in my answers on GitHub. Examples:

• this is not a priority;
• I don’t have a time for this;
• I cannot implement it because I don’t even know how it works.

One example of a feature request that people often asked was to create a package for other Linux distributions. I answering saying that I’ve created a installer for Ubuntu because I use Ubuntu, that this issue was out of my scope, and that I’d appreciate any help.

GitHub even has some default tags for this, like help wanted.

And guess what? People started to submit code! Some code improvements, better python practices, packages for other Linux distributions, even the enterprise authentication was improved by contributors!

If your project is popular, if you’re friendly with pull requests, and people really need it, they’ll help!

6. Create a list of contributors and roles

A lot of installers (for Fedora, RedHat, Arch) were made by contributors. And some issues related to them started to arrive.

In my mind, I can remember that someone created the Fedora package, but I can’t remember exactly the author name! (I had to search in the pull requests who made that in the past).

So, keep a list (better in the README file) with a list of contributors, their roles in the project and a link to their external installers.

With that, I could easily answer: this issue is not related to ScudCloud itself, nor the Ubuntu installer, please report it the following project, mentioning the author and the external URL of the project.

7. Be prepared for aggressive/uneducated feedback

Basically I like to work on open-source projects, because I feel that I’m spending my free time helping others with the same problems I had (and a lot of times I was rescued by someone too).

Often I receive some nice personal emails, saying how much my code helped others. Some I even receive emails asking me how to send money! (But I decline, because I’m just sharing something that I’ve made for fun to help me solve a problem).

In the other side, you’ll face a small number of unpolite people, raising issues like if you’re a helpdesk with a paid support contract and their priorities are the highest in the queue.

Well, this will always happen. Be prepared for that. Don’t take it like a personal attack. Sometimes people is not even aware the program you’re sharing is an open source project. Sometimes people will write when they’re really frustrated.

First advice: if you receive any of these emails, and you got angry, it’s to never answer in the first minutes. Wait at least few hours, so you can digest the message. If you really want to express your feelings, write an answer, but never send in the first hours. Review it later: probably you’ll delete it and start again with less aggressive words.

Try to dismiss the aggressive words and focus only in the problem.

And be gentle. Always.

8. Don’t hurt the parent business

This advice is not related to the “almost burnout”. But is a tip for any open source project: if you’re building an open source software for a commercial business, respect their business model.

On Slack, the initial plan is free. You can setup your team, use the chat/collaboration tool, and save your chat history with a limited log size. If you want to see the entire chat log, you have to pick any paid plan.

So, some people asked me to implement a full chat history. Of course this will break Slack business model!

Additionally, Slack support always was very gentle with me. They even included ScudCloud in their desktop client list!

So, my answer was clear: no. And, of course, I always make clear the reasons: it’ll hurt Slack business model; it’ll detour from my scope (make ScudCloud a simple wrapper as possible around web Slack).

Slack released an official client

The project got manageable: I was able to have a life, people was helping, ScudCloud was now the default Slack client on Fedora, still a lot of issues being opened, etc.

Then, some months later, Slack released their official client for Linux. I asked people (on a Github issue) if we should keep ScudCloud. A lot of users said “yes!” for the following reasons: better integration with the desktop; being an open-source client; less memory usage.

Slack client: now for Linux!

The official client was like ScudCloud: a wrapper around the web version. But made with node.js and using Electron as HTML engine (which is build using Chromium, the open-source version of Google Chrome).

ScudCloud was using webkit, just the core of the Google Chrome HTML engine. Until that time, the HTML engine used by other browsers too, like Safari.

And well, people was not that happy with the official client memory usage.

But while ScudCloud was less resource hungry and had better integration with the desktop, it had an obvious downside: at least once a week, it got broken due Slack changing their non documented API.

One failed attempt was a propose to merge efforts with another Slack client for Linux, but the other project said they don’t want to work on it anymore.

Google switch away from webkit

Well, this was not in 2015, it was on 2013: Google forked webkit and named it blink engine.

But at the end of 2015, I started to fell the effects from this change: some bugs started to appear on ScudCloud due webkit not properly handling newest JS from Slack.

Initially I tried to inject some JS in ScudCloud (sometimes just polyfill) to fix these kind of issue, but later they got more hard to fix.

In Ubuntu I even packaged one more updated version of webkit (which fixed some issues for some months), but later even this was not enough.

My options were:

a) Try to use a newer version of webkit, but this will require package it for Ubuntu and other distros;

b) Switch to a Chromium component instead of webkit, the QtWebEngine.

The Sunset

I just measure all the pros and cons about these alternatives, and realized that I’ll spend a huge time working not in the main product (ScudCloud), but working only on a side library (the web engine).

And I realized that while ScudCloud was a nice and popular project, now the official Slack client was good enough. They even reworked it to be more responsive, launch faster and use less memory!

So, at the end of the day, I just archived the project on GitHub.

Some thoughts

Well, after that I got mixed feelings. Happy because Slack released a good Linux official client. Happy because that task was getting too heavy. But a bit sad because, want it or not, it was an incredible journey (and I learned a LOT!).

I still help in open source projects, but now in more focused roles. Sometimes I have some ideas for other projects, but now I prefer help other projects than manage a project alone.

One think that I still didn’t get is the reason why Slack has not released an embeddable version of its client.

I can realize they’re not releasing an API because they don’t want people building different clients and because it’s a way easier use Electron to build a program that runs on all operating systems.

But they could release their web client to be embeddable in other projects, even charging for this.

I even got an email from a crypto currency company offering me money to embed ScudCloud in their trading tool (I’ve declined). But if Slack had this embeddable version, they can charge any company building a program that requires a communication tool.

Well, that’s it. I hope you’ve enjoined reading my journey and my learning during that time. It was really exciting for me!