Open Source & Money
A solid few years ago I finished a talk at a conference and afterwards someone recognized my username as the maintainer behind Apktool. It was an odd conversion in a way because the individual just spoke about how they used it for x,y,z and thought it was great. They then hinted at the millions of downloads suggesting that I must have tons of money due to the popularity of it.
Quick news flash - I do not have a pile of money from Apktool and have only obtained $380 ($280 if you subtract the $100 I gave to the other maintainer) in 12 years.
We will get back to that, but something happened over the weekend that re-sparked all these thoughts. An open source project for Windows known as "ImageGlass" was caught injecting malware into the project during a commit. This showed up on Hacker News and of course led to an infinite amount of debate.
This was an interesting form of open source going rogue, because the maintainer undid their mistake and gave us plenty of dialog, which is not the norm given the recent situation that occurred with thegreatsuspender. So lets look at some dialog in an recent issue report for ImageGlass.
Yakabuff: I love how you added literal malware to a supposed "lightweight image viewer". How can anyone trust you after this lmao maybe you add a crypto miner next time?
issue 1252 - d2phap/ImageClass
Which was responded in short by the maintainer with this snippet:
Yakabuff what should I do now? I became international criminal after 1 night, and all people from nowhere can come and judge me. Before this integration, I made an announcement to poll people's reaction on ImageGlass discord server for the first release of IG Moon. There were very little comments, I guessed people were fine with the changes, it's been there for 2 weeks. When it came to the official release, I expected there would be more comments, but in fact, people have been insulting me more.
....
issue 1252 - d2phap/ImageClass
This is such interesting dialog to me. The maintainer acknowledges that the greater Internet descending onto his project to interject opinions might not have a place in a project they don't use.
Though, his response of claiming his user base was "fine with the changes" I think is a reach. Most folks have no idea their Internet connection is being harvested for an exit node and I would guess would certainly not agree if given a chance to understand the true purpose.
I disagree 100% with what this maintainer did and it would fully affect my trust towards this individual near forever. So lets run through other possibilities with real world examples that could have been injected into the ImageGlass situation.
Sell the project to another person (one time $$$ gain)
For this, lets turn back the clock to a Chrome extension that I even used known as TheGreatSuspender. I used the extension for free and never once visited the GitHub of the project itself. Call me a poor user of the open source space or probably acting like most and just installing an extension and being done with it.
One random day years later - that extension had an alert from Google that it was malware and automatically removed. I was scared beyond belief thinking all my stuff was stolen so spent an entire weekend rotating every single key, password, and authentication I had. Since this extension was built to suspend any tab, it naturally had an extreme amount of permissions.
So then I went into investigation mode. Turns out on June 19, 2020 the maintainer of the project wanted out after 8 years and hell I don't blame him. Just take a read on my 2017 blog post about the battering you take maintaining a semi-large open source project. He names the new GitHub account to takeover, which happens to be a brand new (at the time) GitHub account named after the project itself. So effectively an unknown user.
On November 3, 2020 a user opens an issue noticing that a new published update of the software has no corresponding code on GitHub. This is odd for an open source project, since a binary release without corresponding code is very suspicious.
Sleuths investigate, reverse engineering and discover ad fraud is at the center of the recent updates. The unknown new entity tries to cover face, by adding options to toggle this behavior into the repository. However, the pull requests and issue reports are ignored. Its clear this new owner was not maintaining this repository, but instead monetizing the repository.
Money I believe sways all opinions, because any project that sees some success in popularity will receive emails from odd places. I remember Apktool getting an email for a simple ask - add one JS script to my documentation site and I would make roughly $1000-1200/month.
The extension was not going to be shared ahead of time, but my guess is something to override links/searches/something malicious. I think open source maintainers have a slightly higher responsibility to protect the end users of their software to pick the ethical path even if its not the money making path.
Sell the compiled project, remain open source ($$$ for ease)
This is an unique method that helps more non-web based software. Imagine a piece of software that is a bit complex to build on your own, but you can easily obtain a pre-built binary for a small fee.
Developers or even technical folks alike could manually build this software or just pay a small fee to have it pre-built. I remember this with a piece of software for a Halo stat tracking program way back in Halo 2. Some C# application that was $2 to have pre-built or suffer through a combination of ZIP files released on a forum to build on your own.
Halo nerds did not like payment at all though as a few smarter engineers just shared the binaries in other areas negating the entire purpose of paying for a download.
Attempt Sponsorware ($$$ to produce)
In this situation, we see a few packages of recent times promise to go open source but only after a certain amount of sponsors are added. This usually leads to a collection of folks buying into a cool looking extension for the benefit of it eventually going open source.
We saw this again with Caleb Porzio, who left his job to support his own packages in the open source space. He followed this idea and it turned out to work quite well growing his salary by $11,000 for a specific package in just a few days in one example.
Though, we now have the benefit of looking back at how this has panned out. Both Nuno & Caleb both requested 75 sponsors prior to open sourcing Pest & Sushi.
- 75 required (Nuno), January 23, 2022 current: 47 sponsors
- 75 required (Caleb), January 23, 2022 current: 973 sponsors
This difference is insane to me, so lets dig into it.
Nuno
- PEST (3,890 stars)
- PHP Insights (4,470 stars)
- Laravel Zero (2,849 stars)
- Collision (4,001 stars)
- Larastan (3,625 stars)
Caleb
- Livewire (14,327 stars)
- AlpineJS (19,651 stars)
- Better PHPUnit (175 stars)
- Sushi (1,387 stars)
So while Nuno's current sponsor count in January 2022 is 47 sponsors - that is under his requested sponsor amount to open source PEST. We can see that Caleb has instead exploded with almost 1,000 sponsors on GitHub.
We can see though that a single project that Caleb created (AlpineJS) has more stars than every single project Nuno has listed in his sponsor page combined.
I think when I look at this above, I see one example that may cause this difference. Nearly every single package Nuno creates benefits the developer directly, with enhancements to tests, console and insights that engineers read. If you look at Caleb's packages some of them have clear features that end up being front and center on a website.
Could this be the difference that no one seems to be talking about? If a business builds a site with AlpineJS - they've bought into supporting it and have to stay with it. If a business attempts PHP Insights and doesn't like it - they can just turn it off unlike ripping out a feature like a chosen JavaScript library. Perhaps the monetary gain is related to where your product is in the ecosystem of technology - the closer to the end user's eye - the more money you might earn.
Find a Sponsor (steady $$$)
Finding a true sponsor overlaps a bunch of the categories we currently have listed. Since a sponsor at times may request features, fixes and constant updates for the stream of funding.
If the company sponsoring you is the company you work at - you may get to re-purpose your work priorities to slip in some open source work at times with no real guide to the specifics. COVID-19 may mess this up with companies pulling funding to stay afloat, but it is a great way to have sustained funding to keep working on a project.
It just has to be clear what the sponsorship entails. Larger companies sponsoring software might have clear requirements what it means, so its always important to realize what you (as a maintainer) might be agreeing to for another sponsor.
Laravel does this in a cool way that sponsors depending on the price have a larger presence on the Laravel website in a marketing way. Since Company A pays Laravel monthly as a sponsor and Laravel in return pushes folks to Company A if they need X,Y,Z done with the software.
Paid Support (ad hoc $$$)
Another interesting method of raising money is just asking for people to pay for support. This is a tough tough thing to do unless you are confident you can solve problems that come your way.
Let me give you an example - way back in 2016 when I was dealing with way too little time and still a solid amount of support requests. I sent this static message to all support requests that were privately messaged to me.
Due to overwhelming Apktool related personal emails I get, direct one on one support costs $50 an hour to triage and investigate problems. Such a large open source project ran by myself simply has no time for personal emails anymore. If you'd like to continue, I'll send an invoice and we can get you squared away. Otherwise you may try the many sources of XDA, searching the bug tracker, Google Groups and Stackoverflow.
In the 50 to 100 of these I sent only 1 person ever took me up on the offer and I'll tell you how it went.
- I messed up the timezone difference and missed initial meeting.
- Met again and problem was difficult, but identified as a known bug.
- Person was upset that I could not resolve issue and instead told them "known issue, unknown resolution"
- Person re-called their $50 via PayPal.
- PayPal sided with them and I lost the $50
I thought it was clear in my messaging that I can't fix all problems, but I at least can triage and identify what is going on. This is a problem I think that is kinda unique to a reverse-engineering tool. Since I don't think its too often that someone supporting a piece of PHP software has an issue that is a low level bug in PHP and they cannot resolve it timely.
So lets look back at Vuetify and Tidelift which offer a way to keep the project up to date as well as providing support. I think this is a solid path
- recurring support for enterprises to know the software isn't going anywhere
- one-off support for that person who just wants some help
The project can stay open source and the funding for support can drive the project to keep been maintained.
Ask for Donations (manual $$$)
The last category, that I think all folks just do no matter what, is an optional donation path for enjoying the software. I've had donations open for Apktool for now a decade and currently sitting at a positive $244 gain, which is roughly $20 a year in support for the project. The costs to me have been near zero until I obtained apktool.org
to own the org.apktool
maven namespace.
I'm trying to show that optional donations don't really work in my personal experience. Though, the perception of what people think is entirely different. Lets take a random Hacker News post where a user is asking how to split up an approved $1,000 donation to open source.
A few extracted comments:
If you were to donate $1000 to "open source", not much would actually get anywhere useful IMO.
I think of it this way, no matter what you give, it's a great start.
In terms of impact, paying for $1000 worth of consulting on an open source project that you use is probably where it's at. "I really want bug #1234 fixed." Pay someone $1000 and it's fixed. (For a bug that takes a day or so to fix, that is.)
A very interesting discussion as legal in a company is the hardest reason donations don't occur according to this thread. Companies can more easily apply for a support contract than do a donation.
This category is one that I've struggled with in the past - I've been guilty in the early programming days of building "All In One" software which effectively just bundles other software together. I got donations, but my software was a weekend project that just launched other software.
In a different example, folks built GUIs for Apktool (cli tool) on various platforms and asked quite heavily for donations. This did bother me, because for a project to push for donations more-so than the project they were wrapping was tough.
This got exasperated further in my brain when I realized that a few popular sites/projects and more simply just wrapped my tool and built a better solution with it. This still happens in large scales with things like Redis and Elasticsearch when license changes occur to force the companies that benefit from these open tools to share the profits or code changes. Though, I don't see this often (if ever) when the project is still led by maintainers. In both examples above - this only occurred after a company sponsor came in to run the show.
At one point though when a salary started coming in and I bought software vs stealing it. I realized that I didn't upstream my donations to smali (a project that Apktool uses) or any of the dependencies that Apktool uses from Guava, JUnit and much more. So this just tweaked something in my brain that is not my place to care or worry about what project asks for donations or who builds projects solely based on another tool.
All I've learned digging up these links and thoughts is that money & open source is such an evolving and difficult thing to perfect. For now, I'll keep my donations open and my open source projects slowly growing.