What happened to Captura? OSS maintainer burnout (2023)
mathewsachin.github.io
mathewsachin.github.io
Lack of proper curation and human communication are among the major reasons to hate app stores.
Free app stores like in Ubuntu often ship versions not polished enough because nobody has enough spare time to really care without being paid, commercial app stores like of Microsoft and Google just don't care and feel Ok welcoming all sorts of scammers as long as they pay the rent, all they apparently do is nuking accounts of good people for no clear reason.
And it's completely legal to resell MIT-licensed code (of course with the attribution).
In this case it appears that the same could have been done, but the author says he "reached out" but did he actually use the right legal threats?
If you have the money to sue them, but honestly it's probably never worth it.
I know many robotics companies who ship systems that contain tons of docker containers, typically running Ubuntu. They effectively do ship a ton of GPLv2/GPLv3 packages but just don't give a damn. Good luck suing them.
I do not think they even have to do that, do they?
All that is required is "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." which sounds like the file with the license text has to be somewhere in the distributed software.
Sure, but somewhere accessible. I don't know about the Windows Store, but say for Android, the user only receives the app as an apk, so the only way I see to distribute the copyright notice to the user is by adding it to some "About..." submenu.
> Despite Captura being licensed under the MIT license, which allows for the application to be sold as long as proper attribution is given, these individuals had removed all license information from the application.
Writing code for free is charity.
I always saw creating open source code akin to being a plumber or carpenter who applied their hard earned knowledge and worked for free in homes they chose.
A plumber who works for free is a rare thing to see, however in software it seems lots of people _expect_ it to be created like that. Not uncommon at all to see comments in HN saying that "oh well if it's not OSS I won't try this software you're showing off". Try saying to a carpenter that if they don't give away their new chairs for free, you wouldn't even start to think of getting one! :)
But then, if you care about the "right to repair" (so to speak) of your software, well at least use a strong copyleft, not a permissive license that basically grant the permission to "steal".
So there are many devs out there that want to win the jackpot. I don’t blame them.
You need to write your own story for people to be aware of it. What most people who have any sort of fame have in common is that they're good at crafting a narrative.
What sets John Romero apart from the next level designer and game dev is that John Romero loves talking about John Romero.
Your blog is much more important than your git repo. I don't think talking is enough on its own, but it is extremely important to put yourself out there.
What I understand here is that you don't contribute to open source projects, but you think that you can understand the motivation of those who do. Let me be honest: I think you don't.
There are many reasons to contribute to open source, and those who believe they will get a salary from sponsors or become famous are naive beginners.
A big difference is plumbers use interchangeable parts and you are mostly paying for their time and skill. With closed source software, you are getting a blackbox that you can't extend beyond what the creators allow and the creators will only extend so long as they are in business. After that it might still be usefull but a liability or can be useless.
I don't mind sharing software that I wrote for myself if it's useful to other people.
I can see why people would sometimes program for fun.
You should open source your code if you don't see a benefit in keeping it closed (usually "you won't sell it" is a good reason). Then maybe some people will contribute to it and improve it: bugfixes, new features, etc. That's great! But every single line you merge becomes your responsibility, so you should only merge it if it improves your project in your opinion. Maybe the feature is great but it is complex, and you don't want to maintain that: it's okay, don't merge it and let the author fork!
Do NOT implement feature requests for free, because this is charity. Either you help people contribute it or you clearly tell them that you won't merge that (but that they can implement it in their fork). Unless they are willing to pay for your work, in which case it's not charity anymore. And because you get paid to implement it does not mean you have to support it for 10 years: once it's implement it, they can fork the project with their feature, and you don't owe them anything anymore.
Your responsibility to whom?
- If your build breaks in the future because of this, nobody will come help you.
- If you decide in the future that you want to cross-compile to a new platform and porting contributed code is a big pain, that's on you.
- If the contributed code results in crashes for some users, they will come back and complain to you.
- Etc.
Sometimes it is very low-risk, i.e. you know for sure that it won't impact many users or that it is easy to revert if necessary.
Sometimes it has a fundamental impact on your codebase, and if you build on top of that then it will be very hard to "just revert".
It's the job of the maintainer to decide what kind of risk they are willing to take. The thing is that many contributors don't understand that and put a lot of pressure to force their contribution in. And that's how you end up burning out the maintainers who try to be nice.
Apples to oranges; if a carpenter tried to sell me a chair that could take actions against my best interests and that could just disappear or stop working one day or that I wasn't allowed to repair myself, I also wouldn't even start to think of getting one. I avoid proprietary software because it has a long history of going out of its way to screw users over; that it often costs $0 is secondary.
It is a complete, all-in-one tool - very straightforward UI, lots of formats supported (especially through ffmpeg integration) and very easy to use in terms of window or screen area selection for recording - and more importantly for my use-cases, it's portable (no install, no admin rights needed). Really a great example of what's possible in that space.
I didn't participate in the project, but I've checked out the PRs and issues list every now and then and it's been frustrating seeing the author struggle against the store republishing issues for literal years. The issue tracking that (#405[1]) is not a happy read for sure.
The fact that Captura's MIT licensing gave effectively a "license to steal" to people and that it's so easy to publish something and sell it on the Microsoft store didn't mesh well.
I've however been really disappointed by Microsoft's non-response through all of that republishing debacle. Republishing free software is a difficult topic to get right for edge-cases, sure, but the Captura case was obvious to rule on and Microsoft did nothing for years - it was clear that there was no process for this kind of scenario, and that the solution was to do nothing. It took the author taking down the project for them to react, and even then I'm convinced that's only because whoever handled that case assumed that the republisher was the one taking it down, not the project author.
Fortunately, I won a Microsoft chalenge about apps development. I had the opportunity to go to Seattle and assist to the next Microsoft mobile OS (Windows Phone). At the presentation, I took the opportunity, during a coffee break, to explain my situation to the presenter. He was so sorry and gave me an operational contact. Days later everything was resolved and I finally received my money.
Lesson learned: Microsoft is a huge bureaucracy but you can manage to find real involved and competent people. As a French person, I know how to deal with bureaucracy: avoid it if you can. I switched to other development platform and never go back to Microsoft.
You solve your problem and share the code for everyone to use. They can fork and change it to solve their own problems, you've finished working on it a while ago.
And yes, being paid should always be an option.
The only question seemingly no one has solved is: how?
...especially so that everybody wins - individuals and corporations, benefitting from said software, the maintainers _and_ their collaborators (sidenote: that's something that kinda grinds my gears - sponsored projects receive all the dough, with their various collaborators essentially working for free??) etc. etc.
Folks are just ignorant of licensing the majority of the time. GPL is why Linux is still around :)
https://web.archive.org/web/20120620103603/http://zedshaw.co...
> Why I (A/L)GPL
> I want people to appreciate the work I’ve done and the value of what I’ve made.
> Not pass on by waving “sucker” as they drive their fancy cars.
1) Someone paying for my product means that they now expect support and maintenance for me. When I release my software under a Free license, I release it "AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED", which I think is the best part of Free Software. You are responsible for using my software.
2) As soon as you start accepting compensation for your project, you now have to deal with a whole bunch of legal overhead, taxes etc.
I think the main issue is people releasing their software under a license which they don't necessarily agree with beyond a certain point.
In worst case you give a refund if the software doesn't work as promised for the customer. You're not forced to fix bugs or problems that are beyond your capability or interest.
Taxes are not a big deal and can be ignored until you start making decent money on the business and can afford your accountant. The taxman understands and is not going after people in the starting phase.
It's a ego thing then. Anybody doing free/open source software should make peace with the fact that their work is given for free. Imagine Linus Torvalds complaining that people are selling his work.
I think a lot of maintainers just aren't asking for them with any sort of clarity because it's uncomfortable and you're kinda putting yourself out there. It seems pretty common that you kinda have to go look for ways of funding a project, and it's like buried in the back of the website somewhere.
Willingness to donate also seems to really depend on the type of project. It appears easier to get institutional support, or individual "whale" donations, if your ambitions are a bit loftier than if you're building small individual widgets or libraries that do one thing well.
I think people are perhaps more willing to pay for what a thing might become than what it is today, when it's more like an investment than a payment for goods delivered.
Small time developers should come over to the Mac side of things, where users are happy to pay a fair price for apps of any size, and especially boutique apps. That's how I as a user respect the developer: by paying for his work.
That said, a lot of open source software faces issues with funding and also developer burnout, or something other reasons for a project just... ceasing. Like there's this lovely piece of backup software called BackupPC, that covered all of my needs, but there hasn't been a new release in forever: https://github.com/backuppc/backuppc
What's worse, sometimes the community is just left with no status updates, and don't even know whether a project is abandoned: https://github.com/backuppc/backuppc/issues/518
In cases where nobody cares enough to make forks and keep it alive it just... fizzles out.
This might sound a bit off, but I sometimes wish there was a feature where you could say: "Hey, I'm willing to pay X$ for the maintainer of the software to address this issue on GitHub or do a release, I've placed the amount of money in escrow and it will be released to the dev upon completion." With enough people pooling resources together, how much the community actually cares would be quite obvious and the devs could actually benefit from OSS. Donations are too unreliable and detached from the units of work done (I've done some donations in the past, but would do more monetary contributions for specific issues). If streamlined enough, it wouldn't be different from buying the developer a beer, or the equivalent of Patreon or Kofi.
However, there is a large number of FOSS devs that don't give two shits about your money. Oh hey! Isn't that nice? Doing something you love, and something that brings value to your fellow human, without it being tainted by money?
Some people view the need of money as the problem, and the lack of it involved in their project a very conscious decision.
Yeah, that's why I think a bot for aggregating/suggesting financial support would be a good idea. Then again, when npm package maintainers were looking for donations and output that in the console, there was a lot of backlash, so I suspect similar opposition would happen to a bot commenting: "Hey, this project accepts financial support. If you'd like to indicate that this issue matters to you, you can optionally put money in a reward pool for this issue here: some_link. Money in the pool so far: X$."
> However, there is a large number of FOSS devs that don't give two shits about your money.
That's fair, but definitely isn't the situation for many, especially those who don't have cushy day jobs and are either financially struggling or just feeling the pressure of our current economy.
Articles like this come to mind: https://staltz.com/software-below-the-poverty-line.html
The whole log4j debacle also comes to mind, summed up by this xkcd: https://xkcd.com/2347/
> Some people view the need of money as the problem, and the lack of it involved in their project a very conscious decision.
That is admirable, but you can't eat praise. Either way, that is their choice.
I just feel that if there are a lot of companies extracting money from people with disposable income in the form of mobile games, gacha games and microtransactions wherever you can, as well as if there's a commonplace tipping culture for restaurants in many countries, might as well take the same principles and apply them to get some money in the hands of deserving developers.
I'm not saying that it'd necessarily decrease burnout or solve the other issues about open source, but at the very least it'd give some financial stability. If people aren't urged towards that, very few will donate of their own volition, call it psychology.
Is this the case here? I don't know.
Mind you, this happens regardless, but it get's harder to ignore if you actively want to build community.
I, for one, dabble in small, focused FOSS projects to keep myself sane in a world where working on a team on a feature-creeping project is the norm.
Questions raised like how do you find these people, are they paid? Legalities and how to make money. Now you have to organise and lead a group of people. All of that isn't why most people want to write code.
Has anyone shared some sort of analysis of external/community contributions to Hashicorp's OSS products, following their licensing change, to then come to a conclusion about some "internal to external" contributions ratio that would justify all the frustration with which that decision has been received?
I mean, people tend to always assume that OpenSource software is the ownership of a world-wide community of contributors, and not the person (or group of people) that had initiated it and decided to share the code; but, I've hardly seen cases outside of these two, when serious problems surface:
1. Indie OSS maintainer that suffering from some burnout, or even struggle to make a living, while their work is being freely used by thousands of people, and even help dozen of companies make money in some way.
2. OSS project that is mainly supported and maintained by some company/corporate, to the point that if they would ever decide to stop doing it, the software would not as actively receive significant fixes/updates (if any). Which basically means: the sofware is freely available (along with its source code), mainly because there are people paid to work on it.
GitHub and VS Code and npm are going to start really squeezing now that the switching costs are so high. Get out while you still can.
Is this from the github page itself or from github?
I bet it has nothing to do with GitHub, they're just rendering whatever is being deployed.
For companies, it is about control. Google did not care about contributing protobuf to the world: a company does not "care", it maximizes profit. Open-sourcing protobuf was most likely not a big cost, and it had benefits for Google (otherwise it would not have been rational to open source it). For instance, Google benefits from external engineers who already know protobuf when they join Google (no need to teach them). Google can benefit from external projects exposing a protobuf API (though I am not sure if that is frequent), and by having protobuf out there, they keep control: the biggest issue of Cap'n Proto is that it does not support all the languages protobuf/gRPC do. If protobuf was not open source, something like Cap'n Proto may take its place, and that's not good for Google. Same goes for Chromium or AOSP.
For individuals, there are two cases: as employees and as "hobbyists" (for a lack of better term):
As an employee, I benefit from my code being open source: I will keep access to it after I leave, and it serves as a portfolio you can show when you look for a new job. I really, really do NOT understand why software developers are NOT systematically pushing very hard to get their code open source. Many times you just need some kind of "yes" from a manager (even if they did not really understand the consequences) and once it's open source, it's done. And many times it does not impact the company at all (and honestly, why should you care?). I have this Marshall home smart speaker that is pretty good hardware, but the software is a piece of crap. Marshall does not benefit from not making it open source: people like me would make their speaker better. Not because I want to help Marshall, but because I want a good speaker and I am ready to work for it. It's just that nobody at Marshall cares/understands.
As a "hobbyist" (again, bad term but I don't have a better one), it is a bit of a philosophy. I like using open source software, because I can compile it for my specific needs, I can debug it, I can tweak it. If I am aligned with the creator, I can even contribute upstream as long as I do benefit from it (mostly because I need it or I enjoy it). The risk is that someone else may resell my code, but let's be honest: if I could sell my code myself, I would not make it open source. Of course it's frustrating when someone else makes money from your work, whether they honor the attribution clause of the MIT license or not. BTW if you don't want to live the frustration of seeing a business make money from your work, a good start is copyleft licenses. They can still make money from it, but at least they contribute back to your project. I just don't understand why hobbyists go for permissive licenses at all.
Now hobbyists (like the maintainer of Captura) need to really understand that they don't owe anyone anything. You work for free, you should work for yourself. If someone wants a feature you don't care about, don't implement it or make them pay for it. If they are being jerks, ignore them. If they fork away, great! And IMHO you should favour contributions to projects that have a copyleft license. If you contribute to permissively-licensed projects (or if you sign a CLA), then you are not allowed to be frustrated when the company makes money from your code without giving anything back.
Nah honestly it was more like I said "Hey I want to open source this!" and other engineers said "Yeah that sounds awesome!" so I did. That was Google in ~2007, you could basically do whatever you wanted and as long as it was vaguely plausibly useful management said "sure".
I'm honestly not sure the company had any idea what they should do with OSS protobuf, at least for many years. Management never really gave me any credit for releasing it and gently pressured me to find a different project to work on that more directly aligned with company goals, which I eventually did.
Still not clear if they even know today. They seem more serious about it today but at the same time it's still clear that they mostly don't care about external users, so much so that startups like https://buf.build have to come in and build the actual products around Protobuf that Google never delivered publicly (but has internally). Of course, companies are not hive minds -- there are clearly people at Google who want to make Protobuf a great product and are trying to do so, but I don't think management sees it as strategically interesting, so they face headwinds.
> If protobuf was not open source, something like Cap'n Proto may take its place, and that's not good for Google.
Honestly I don't know if Google cares. Cap'n Proto hasn't caught on much because frankly I don't care to make it a product, I maintain it for my own use (primarily in the Cloudflare Workers runtime, my day job). But if that changed and Cap'n Proto got really good and people ditched Protobuf for it, would it really affect Google? I kind of don't think it would. (Just like I'm not sure it would benefit me that much, which is why I don't make this my job.)
Certainly the strategy around open sourcing something like Protobuf vs. something like Chromium or Android is entirely different. Sundar probably doesn't even know what Protobuf is TBH.
(Disclosure: I wrote and open sourced proto2 while at Google, created Cap'n Proto after, and have a small investment in Buf.)
Yeah I was just speculating with a well-known project. Sometimes it doesn't matter to the company and some engineer manages to open source it, sometimes it is a strategic decision by the company, and sometimes the company does not realize it would be a benefit (I believe in my Marshall example).
> Cap'n Proto hasn't caught on much because frankly I don't care to make it a product
And that's your right, and people using it need to realize (or you can correct me if I'm wrong) that unless they make a contribution that Cloudflare cares about, it's probably not worth contributing at all.
Reminds me of this very similar criticism of Signal recently [1], where someone was frustrated because they spent time on a PR that never got reviewed. I do understand it is very frustrating and it happened to me as well (I put quite some effort in a project and it was lost because the maintainers did not care). But the lesson I learned was that I should just be wiser when I decide if I want to contribute to a project or not. And for projects that essentially belong to companies (which I understand is currently the case of Cap'n Proto, since you say that your time right now belongs to Cloudflare), then probably it's not worth it. I guess if I reported a bug that affected Cloudflare I would not even have to bother fixing it myself: someone at Cloudflare would.
But contributing to someone else's codebase is tricky. A lot of times, it'll take the owner more time to review your contribution than it would have for them to build it themselves. This is true even if you're a great engineer, because (1) even great engineers need to learn a lot when entering a new codebase, and (2) the owner doesn't know if you're a great engineer so has to assume the worst and review everything carefully.
If the change is a small bugfix, no big deal. If it's a major new feature, even if it's a feature the owner wants, you have to understand that opening a PR isn't necessarily a gift to them.
With Cap'n Proto, I maintain the core C++ implementation. I'm happy to accept small fixes but when people try to implement big new features, yes, it has been rough. I spend a huge amount of my work hours reviewing code for my team, all of whom I know well and were vetted through a hiring process, and I still find that stressful. A random large PR opened by someone I don't know... eek. But I do feel pretty bad about the big PRs that I've failed to review.
On the other hand, if someone wants to build a Cap'n Proto implementation in a new language, it's much easier: they get to own that codebase themselves, do it how they want, and I'm happy to link to them. That said, unfortunately, doing it this way has led to some pretty variable quality in per-language implementations which is Cap'n Proto's biggest weakness.
I meant it more in terms of resources: you seem to be saying that you maintain Cap'n Proto as part of your job at Cloudflare. You mention PRs that you have failed to review, I guess Cloudflare did not need them. And as you said, if Cloudflare had needed them, you would probably have been faster doing it yourself. Which also means that opening those PRs was a loss of time for everybody from the beginning on.
At least that is more and more how I see open source:
- I have to "blindly trust" some projects (e.g. a standard lib, TCP, protobuf) because I couldn't maintain them myself. I try to minimize that and chose those carefully.
- I accept to depend on projects that I could easily fork or replace. I can contribute to those, and if the maintainers ignore me I just fork away.
- If it's small enough, I'll rewrite it myself (using the open source code for inspiration).
Conversely, I behave more and more like this as a maintainer:
- I don't hesitate to tell people that I won't take time to review non-trivial PRs
- I encourage people to fork if they want something I cannot give them
- If people cannot fork and need something I cannot give them, then they are screwed. That's sad, but that's life. I can't burn myself out for them.
I use to say "PRs are welcome!" when people asked for new features. I stopped doing that unless I am really sure I will actually review them.
It's like they took entirely wrong lessons from App Store.