Making a living on FOSS is hard, as you discovered.
I hope you succeed, of course. But since I have no good idea what your app is, except "a browser for developers" from the blog text, there is really no chance that I would ever search for this app, hear about it thru word of mouth, or eanything really that would make me end up testing your app.
Here's some other ways you could have tried to approach the situation:
- stop providing compiles, while selling access to the compiles on patreon or something. this way you can keep engagement from other developers and stay FOSS.
Aseprite is doing it. Compile for free or pay 20$ for the binary. I compiled once but the next time I just thought to hell with it and bought it on Steam )
When talking about GitHub stars and money, it's important to understand the other side of the equation.
A useful free and open source project garners GitHub stars and general recognition because it is useful, but also because it is free. The stars are the social compensation in this case. The free nature of the software is essential to that relationship.
The ‘free’ part in ‘free and open source software’ refers to the freedom given to the user of the software to read, modify and distribute the software that is provided to them [1]. It refers to that freedom and is independently of the price that obtaining the software has. Free doesn’t mean it has no price, creators can profit from it.
In the philosophical sense, sure. But given the context of this conversation, the fact that you don’t have to pay to use GitHub projects is absolutely relevant to their success.
I agree with you on that, sure. I think being gratis overlaps with being free… I think?… Having free access to the software means being able to use it and distribute it. I guess profit comes most of the times from support or distribution of the software, or the binaries. I have read this post [1] on the topic referenced in the Wikipedia article I mentioned, I thought it was interesting.
And then on the other extreme you have something like substack in, which writing political rants easily earns $50-100k/year in recurring donations even if you are not that famous. It's hard to get people to donate open source projects.
Or you can get great conversations going, help struggling strangers get up and become pillars of their communities. Which sometimes requires deleting snarking comments, ban aggressive repeat rule offenders and deal with occasional personal attacks.
Moderators have powers, use power and are often not at liberty to reveal all what went into their decisions. Moderation on any scale is however a team effort and is then subject to scrutiny, discussion and review. Power tripping moderators will be removed by the team and in communities with a sole moderator who is on a power trip it will not thrive.
Subreddits thrive mostly based on their name. If a power tripping mod gets on top position of a good name, there is very little you can do. You can try to start an alternative but all new users will go to the other one.
Reddit Moderators, Forum Moderators, Chat Moderators, Blog Writers, Open Source Developers.
The Internet is built on a lot of great people doing things for free. That doesn't have to be a bad thing if you are okay with it. But always make sure you feel good about what you are doing. If you get enjoyment or a sense of accomplishment (to quote EA) out of it then it's no worse than playing a video game or watching a tv show.
I’ve been a mod for less than 3 months, someone just needs help moderating. Not sure if I agree about power, majority of users in our sub are kids and they can get wild if not moderated.
Because you were asked. When standing out in a forum and demonstrating consistency, responsibility and supporting attitude you may get asked.
Larger boards are like organization with promotions. Abuse of power won‘t earn you one. There are steering structures. Sometime one has to adjust what moderators do and have a discussion on what happened. Occasionally one has to kick a moderator out.
If you don‘t know why people help strangers then this may be worth a thing to investigate for you.
To me it felt like volunteering to keep the community running smoothly.
However it makes you an especially visible member of that community, especially to its worst elements. The constant hostility and eventually the harrassment made me step down.
Now I watch other moderators go through the same motions. People are absolutely vile to them, all over a tiny internet forum.
I would consider Reddit a bit more than a `tiny internet forum`, even thought many topic-specific subreddits are way less useful than an actual forum would be...
The problem with mods is that some of them behave badly enough and go on power trips banning people for their own enjoyment and making tantrums, thus giving a bad rep to the whole category, including those who are actually good people with sane principles.
This is a great encouragement for developers to not undervalue the usefulness of their apps. Most software is free (ad supported) that should be paid for directly instead.
I continue to think that the best model is the one adopted by Fody.NET[0]. It's open-source, on GitHub, under the MIT license, developed in the open, and with a voluntary OpenCollective. And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. The result is a system that is paid enough to be excellent, excellent enough for most users not to need support, and non-bogged enough for paying users to get excellent support.
The best part is when corporations get involved. A company will absolutely get something for free if it can, but if it has to pay, it'll pay a lot more than the absolute minimum, for PR reasons.
It's a UX thing. The "auto-close" behavior makes the policy obvious.
And presumably the maintainers are not bound in any way to not re-open an especially good/important bug. It just makes makes non-patron support opt-in, instead of opt-out.
That logic (your last paragraph) essentially assumes that people only care for selfish reasons. Plenty of people contribute for the sake of giving back to the project (by e.g. taking the time to write a high-quality bug report or PR).
In practice, excepting for major issues. In principle you are supposed to donate in order to use it at all, and the issue tracker is simply where they check to make sure.
I'm not sure how I feel about this one. Sure, the maintainers have no obligation to review and merge other people's PRs. But when this also applies to genuine high-quality community contributions, I feel like there must be some negative side effects.
I'm sure this model works well for an established project like Fody that's already quite highly polished, but I'd be pretty sad if all (or even a significant subset) of open source adopted this model.
I'd definitely be interested to hear any counter-arguments to this though. Are there any avenues for individuals to contribute for free, if they aren't using it for profit?
I like it personally. Free to use, pay for support.
The distribution of something already made is free. Supporting, understanding your issue, developing a fix and releasing it…all of that takes a real person’s time.
As a contractor, you learn very quickly that people will ask for anything if it doesn’t cost them anything. There are a lot of people happy to take advantage of you if you let them.
I totally agree for things that would normally be described as support (e.g. feature requests or low quality bug reports), but a lot of things aren't that.
Personally, if I submit a bug report or PR to an OSS project (which admittedly doesn't happen very often), it's almost always because I think the time I've spent investigating the bug/feature could benefit other users of the project.
For my use cases, it's generally much faster and easier (at least in the short term) to just fork a project and make whatever change I need locally, than to wait for it to go through review/merge/release in the original project.
Another commenter has pointed out that they make exceptions for certain types of contributions though, which I guess would help with this.
But it is MIT, can't I use it for free?
Yes all projects are under MIT so the community backing honesty system can be ignored and Fody used for free.
Do I need to be a Patron to contribute a Pull Request?
Yes. Users must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging.
Do I need to be a Patron to raise an issue?
Yes. Users must be a Patron to be a user of Fody. As such when raising an issue (question, bug or feature request) and not a Patron, the issue may not be actively triaged, and eventually closed as stale. Issues from non-Patrons, that are bugs and are highly likely to affect the larger Fody user base, may justify the effort and be handled.
Also, the minimum amount is $3/Month: which surely isn’t near enough to pay for their time! Many developers can afford $36 a year, and if not, a developer can still use it for free (BSD licence) and maintain their own branch. https://opencollective.com/fody/contribute/patron-3059/check...
You realize that my dependency stack contains about 2500 dependencies right? If they all follow this model I’m looking at $90k/year just to contribute to a project.
Do you PR or raise an issue to every package you use? You can still use 2500 different packages for free. This seems like a good example how it would work well.
My point is that you are taking their point too literally.
Also, the business model is paying a subscription for the right to submit a pull request. Sure, you could wait until you are about to make the PR to buy the subscription, but that's a pain of its own.
Their point here is that this isn't a scalable business model. That's the assertion that started this whole comment thread.
If we got subscription to dependencies, we would get only 3 or 5 deps, only required app to run. No more `is-array` like deps. Adding a new one would be deeply thought and reviewed.
To contribute to 2500 projects yes it would cost that. Otherwise your current rights or license that lets you use those dependencies already should be fine.
> You realize that my dependency stack contains about 2500 dependencies
That is amazing: when I was younger, sharing code was a goal, but absolutely nothing could prepare me for your world. Previously I have had the luck to be able to rewrite a lot from scratch, removing most runtime dependencies, although definitely not replacing build dependencies.
I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?
I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?
Modern devs don't care. They just install whatever, let it pull in 1000s of other packages, and continue on their merry way.
Meanwhile, a package you use today, can root your stuff tomorrow. That is, next update and bam!
Package was sold to Evil Entity, or just the dev decides to rm your drive based upon geo location.
I get paid a lot to cleanup much of this mess, and while tools such as composer and node.js are useful, they are a horrible, horrible security risks.
If you use node or composer, be prepared for dozens of updates weekly. Each update risk laden, and feature and security fixes all mashed into one.
On a large project, you'd need multiple devs, just to audit all the change.
But as you will soon see, there will be all sorts of $reasons given, which all lack understanding of how traditional Linux distros handle updates, and boil down to "not my problem" or "someome else magically makes it safe!"
Have an unobvious copyright condition, get your code in thousands of projects, then spider the internet looking for companies that use your code, and charge them a $1000 “licensing fee”.
Or change the copyright in v1.1.2.2 and wait until everyone updates, and do the same thing.
> Modern devs don't care
I think the “modern” is superfluous and vaguely insulting: security isn’t/wasn’t cared about by most old-skool developers either!
For simple patches on my end, I'd port them forwards. For complex patches, I might hard-fork development and find like-minded people to send patches to me instead of the original upstream. Or if the codebase or changes are too complex to work effectively with, I'd abandon the project and treat it as radioactive and failing to satisfy my requirements (or even be correct).
I think this may be a case where because you have a bunch of freedoms, you feel like you should have more.
I say this to re-assure you, not critisize you.
Open Source, and Free Software, are very clear on the 4 freedoms you enjoy. You can use, modify, distribute etc.
But it's not a 2-way street. You have no rights about what goes back into the project, the author is under no obligation to receive code contributions, no obligation to add features, fix bugs, or anything like that.
Of course lots of projects actively seek out contributions, but it's certainly not a requirement - nor (IMO) should it be.
Coversely open source has struggled to find viable financial models. This sounds like a success story and we should look long and hard at any successful financial model.
So, I don't think you should feel unsure. If you want to contribute then chip in some loot. If it means the project becomes sustainable you are the big winner.
But most of all, I think, be careful of adding "more freedoms" to your understanding of OS and FS, when they don't exist.
The logical conclusion of everyone taking the model of "pay me to review patches or read your issues" is fragmentation. Instead of a vibrant ecosystem where people collaborate on patches and the project grows, the issues and solutions remain internalized in private forks. Is that a better outcome? From the time/money standpoint it's great, and it may make the project more sustainable since there are fewer issues and PRs to review, but it hurts the project long term.
You have articulated well the trade-off between "project first" and "business first".
From a user point of view, project first is the only thing that matters. There is an instinctive resistance to anything that gets in the way. On the other hand users generally don't care about the project authors getting paid or not.
From the author side, getting paid is often a goal. If that means limiting the community to paying users, then so be it. From their perspective they are offering value, and they choose to spend their time focused on users who are paying.
In other words they need your money, not your code suggestions. They can code, but code doesn't pay rent.
As you say, others can choose to silo their changes, and not post them back, that is their right, and indeed likely happens anyway.
I'm not saying I think the maintainers have any obligation to do things for me (I tried to make that clear in the original comment). What I was really trying to say is that I don't think this model would apply well to most projects, as the GP was saying.
To take an exaggerated example, if I tried to use this model with any of my small OSS side projects, the only result would be that no one would contribute. This model means that the development of the project is going to be almost entirely driven by:
a) The original maintainers of the project (who will rightfully get bored of maintaining it at some point), and
b) The handful of companies that have financial interest in a certain bug/feature.
Again, that's probably fine for projects like Fody, but certainly not all of OSS.
> This process will depend on the issue quality, and the impact on the larger user base.
So, if I understand correctly, they won't automatically close issues if you aren't a subscriber, but the bar for the quality to keep it open is probably significantly higher.
I don't think that's a bad model. Although, I don' think it would scale well to every open source project having it's own subscription stream. But maybe if there were companies that maintained collections of projects?
Depends on where the bar is set but as long as "A PR that fixes actual bug with nicely written code" passes I think that model is entirely fine (especially in modern era when it can bet mangled thru test suite via CI and merging it is near-zero effort for maintainer).
That's essentially someone helping your paid customers to have better product for free.
It doesn't work if the project hasn't had any new issues in a while. There is no incentive to be part of the OpenCollective if the project is completed and has no bugs.
I've been struggling with this issue with my project. It's a completed project, no scope creep, no bugs, just occasional update once every 6 months or so. The docs are complete and detailed so nobody needs extra help; no one will pay for support
At the same time, I know for a fact that if the project was buggy or had gaps in the documentation, nobody would use it; they would use an alternative solution from a big corporation.
The level of competition is so intense that there is no room for profit, no room for missing documentation and no room for bugs on my end. Competing products are backed by a big name brand tech corporations; so they can have bugs and gaps in the documentation and users will forgive them.
Branding is extremely powerful. Once people trust a brand name, they will ignore reality. If you don't have a brand name, you need to be 10x better to be perceived as the same quality.
Perhaps it would be helpful to articulate what you feel you are missing? (I'm presuming money, but I don't want to put words in your mouth.)
It sounds to me like you have a solid project, and some number of users. With good docs. Which is great (we'll done.)
I'm assuming you want to monetize it? That seems to be the logical next step. Alas I'm not going to be very comforting with the next bit.
A) the time to think about monetization is when you start the project, not when it's done. Obviously a lot of projects get done for reasons other than money, and when you started you may have had other reasons. That's fine. But monetizing after-the-fact is a very difficult, dare I say "unsolved" problem.
B) this is going to sting, but most successful money-earning products have nothing to do with the code, beyond that it exists. A "business" requires more than "product" - a lot more. Marketing, sales, revenue, administration and so on. All of this is expensive, hence the need to have a business plan (ie, how does this thing make money?) before you start.
As developers we have a code-first mindset. But we try and compete with companies that have a business-first mindset. Companies are winning.
The fact that your project is complete, that it is solid is fantastic. Well done for that. However turning it into a business may be impossible, or expensive. That's OK. Celebrate what is is, don't pine for what isn't.
If nothing else you've learned the difference between a code project, and a business, and if you internalise that then you will have gained something of high value.
Which makes sense in a way because part of the brand is “we’ll be around in 2033 to support this”. And “need help? see myriad answers on stackoverflow” and so
on.
I'm not saying that Fody's model is superior to selling retail software, if what you are in the business of doing is selling retail software. I'm saying that it's superior to giving up on open source monetization if what you're in the business of doing is open source.
Fody says they have an “honesty system” and expect all users to pay, even if they’re not raising issues or PRs. That’s despite the fact that the code is MIT licensed.
How is that a more ethical, straightforward, or profitable business model than just GPLing the project and offering proprietary licensing?
Releasing code under a permissive license, then calling people dishonest when they use it according to the license but not the authors’ desires, seems silly and inefficient.
>And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy.
Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and you reject it because you want me to pay you first, I'm dropping your software without a second thought.
>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library without a second thought.
You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.
Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.
They are entitled for attention, yes. And if they respond to code review and ready to address comments, they will likely get it merged (depends on the project and the PR, obviously).
The requirement to be a member of a collective is a filter. For popular projects it will likely do more good than bad. For niche projects, it might be worse than no filter.
> You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
They were explicitly talking about PR for a bug, not unwanted feature.
Yeah, sure, there is occasionally low quality bug fix that's problematic issue (bug should be fix but the code to fix it is garbage and nobody wants it) but I think that's rarer problem
I can understand too, but I won't even dig into your code when I need to pay you first. Shouldn't you pay me too for opening the pull-request, because "I did your work"?
I do check the LICENSE and CONTRIBUTING files before I contribute. It is likely that I would have not contributed to such a project in the first place. It doesn't change my point, namely that a project where I cannot contribute fixes for bugs I encounter is one that I have no desire to use.
BTW, the reason I mention sending PRs for bugs I encounter is that, when I do encounter a bug I don't immediately file a GH issue and make it the maintainers' problem. Instead I act upon it just like the maintainer would, by checking the source to figure out why the bug is happening, `git blame` etc to see what commit added that code, whether the issue I'm encountering was already identified or discussed when that code was committed, and so on. So as a result of doing these things I often end up either knowing my issue is by design and that I was doing something wrong, or end up having enough knowledge to be able to construct a bugfix myself.
> I'm dropping your software without a second thought.
Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
Pull requests take work to review and test. You shouldn't take that for granted and assume everything will be merged for free.
If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
>Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version.
Nonsense. You think signing yourself up to maintain a patched version of someone else's code for eternity is better than using someone else's code? You have to sign up for upstream CVEs, keep updating the upstream base and rebasing your patches on top.
>Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
False dichotomy. A library is measured in various dimensions - how well-maintained it is, what features it has, OS / hardware dependencies, performance, etc. Something that is better in one dimension might be worse in another dimension, so that there's no single objectively better library.
>If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
I have my own work to do, not maintain forks of other people's code.
The page I linked was the FAQ, which addresses this exact point:
> It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging.
Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
> Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
Fine. But if my code is useful, and it ends up convincing more users to become Patrons, will I get any financial gratification from the Fody maintainers? Or are any profits from this contribution going solely to the maintainers?
In your average open source project, backing it is separate from using it and contributing code to it. My contribution would therefore benefit all people, including those who cannot pay. But the Fody maintainers consider them to be freeloaders and unwelcome people, so I have reservations about contributing and what the benefit from my contribution would be to others. I'm not working for free for a for-profit entity.
>Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
No, I really don't.
https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.
https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.
https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.
etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.
Also, to be clear, there is nothing special or unique about what I do. All large community projects where the users greatly outnumber the developers continue to work because of PRs like these from their users.
Thanks for pointing this out, I've never heard about this model before. Sounds quite reasonable to me. The only problem I see is if they treat all requests equally. I'd be concerned if security related PR get cancelled because the submitter is not subscribed. From my understanding they do pre-screen submissions before cancelling so that shouldn't be the case (at the price of creating some overhead for them).
I think the part of this that's weird to me, is that non-paying users are able to open issues or pull requests at all. Something about it feels very passive aggressive.
Why not just have the public facing project be a fork of a private, access protected project where bug tracking and PRs are handled, that only patrons can access?
For some reason, saying "only patrons can access our development repo" seems perfectly reasonable, but saying "we'll close your bug report if you don't pay us" feels a bit grumpy.
While I'm always excited about new ways of monetizing open source, if I'm looking at the OpenCollective contribution page for Fody correctly, this model has made them under $10,000 in the past 2 years or so.
From a business perspective that's basically a rounding error and nothing compared to what you can do with the conventional approach of selling consulting/support or, heaven forbid, your own proprietary solution.
So in what sense is this the best model? Has anyone used it to generate $100,000 in annual revenue, let alone say $10M+? More profitable model = more hiring developers to improve the software...!
It is indeed terrible from a business perspective, because Fody isn't a business. It's an open-source project. If you want to start a business, you should start a business. The author of TFA wasn't under any illusions it would completely replace her day job, the problem was that it wasn't worth spending the time on after the day job. There's no substitute for selling retail copies / subscriptions, but within the realm of open source for all, Fody's model is the most efficient way of converting appreciation into a little extra cash.
This is a deceptively insightful comment. At least it wasn't clear to me for a while.
If you want to start a business it can definitely have an open-source element to it, but that's just it. The open-source part is just one piece to a business and you better be aware of all the other pieces that need to be done in order to make money which aren't always engineering/programming related. EG: marketing, sales, consulting, fundraising, accounting, etc...
A common approach that people do now is create the open source offering then run it as a service where they can charge a premium for the support and leg work for hosting it. See: mongodb or elasticsearch or influxdb.
I haven't found many pure open source solutions where all they do is make the software better all day and ignore all the elements of business growth needed. Maybe the Linux foundation is a good counter example but I don't think there is a clear path to be paid for just contributing solely to open-source while neglecting other business elements.
This is a poor choice for a donation-driven project because it allows easy proprietization. It also does not protect from patents, tivoization and so on.
> And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy.
I don't know enough about the resulting system, but this sounds quite silly and contra-productive. Issues often hint at important flaws. If the community is not open (Ha!) to outsiders notifying them of important flaws, then that is a recipe for bad software. Some people might go there and start asking for features, instead of describing issues (although even that can be valuable input), but in my experience people are more often reporting bugs or asking how to do something, because it is not well described in the docs, or the docs are not as visible as they should be, or probably many other good reasons. Closing ones door to these valuable inputs can only result in worse software.
Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs. The issue with open source tip jars isn't that they're expensive, it's the psychological barrier in front of giving anything at all. That's the subject of TFA and Fody's model is the only real way to circumvent it. Ninety percent of people who submit issues are people who are invested in continuing to use Fody and so should be patrons, and the remainder of the issues are unlikely to be high on the signal-to-noise ratio.
> Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs.
We are not talking about the same kind of issues or people. Aside from the strawman:
People creating an issue with all the detail are already investing time into reporting an aspect of your project. Immediately closing the issues is like giving them a middle finger, for investing their time, trying to help the project.
Sometimes, when I have a problem with some tool being buggy, I consider opening an issue, but sometimes I don't do it, because I know it would be time-consuming. However, when I open an issue, I usually try to provide all required information and maybe even an example to reproduce the issue. I invest time to make it easy for the maintainers to see the actual issue. If they closed that issue immediately and wasted my time like that, I would be very careful to ever invest time again into anything those people create.
A lot of people and companies are making money from Linux, including Linus Torvalds and many kernel hackers. Linux is GPL’d. I think it is hard to make the claim that making money is antithetical to FOSS.
I mean, if you look at amount of "paying users" vs "all users" it still checks out, just that at the economies of scale of Linux even 0.01% funding it is a ton of money.
FOSS is great for doing "common good" code that everyone uses and many sides want to push forward, but not exactly easy to monetize if you're just a dev doing a thing.
Many companies hire people to contribute to the kernel. Torvalds is the name we remember but there are many others.
And that is the kernel. There are also companies like Red Hat and Canonical that make money through their work (more) in the userland. The people that they hire all make money from FOSS.
Edit: For example, look at the “Most active 5.10 employers” list here:
> When was the last time you chose a value above 1$
> you're a saint for choosing 2.5$
> OMFG THIS SHIRT IS 20$
For the record: the dollar sign comes before the number. I'll take the downvotes, I just can't stand it. I did read the article, and my heart goes out to the author.
> In the United States, Mexico, Australia, Argentina, New Zealand, Hong Kong, Pacific Island nations, and English-speaking Canada, the sign is written before the number ("$5"), even though the word is written or spoken after it ("five dollars", "cinco pesos"). In French-speaking Canada, exceptionally, the dollar symbol usually appears after the number, e.g., "5$".
The linked article appears to be talking about U.S. dollars, and all evidence points to it being written in English, so I don't believe the regional usage is relevant.
It's hard to argue what the accepted usage will be in future generations, but using the dollar sign as a suffix does not appear to have become accepted by any institutions I'm aware of at the moment. Distinguishing a simple mistake from a visionary act of linguistic prophecy is beyond my capabilities.
If you can point me at a reference that makes a good case that the linked article is the accepted usage, I'd be obliged.
I'd imagine people using currencies with symbol after number just do the same for dollar out of habit. Hell I have to fight to remember that stupid symbol is for some obsolete reason before the number.
Regional: Canada can do both before or after number due to French influence--that was mentioned in your link, by the way[0]
Regional: Philippines (personal experience) and many other countries write currency symbol following the number[1]
Generational: starting to show up in texting culture[2]
Having experience with languages evolving due to technology, including a few Filipino dialects, I've observed people adopting new conventions in spite of older generational mores is nothing new. Happens all the time. And as a person gets more experience with places that have different conventions, they typically let go of the provincial views that their learned way is the only way. The dollar sign is not the only chrrency.
Does a US dollar sign after a number look right to me? No, because my grammar teacher taught me differently. But my native French boss flipped it all the time and nothing of communication value was lost.
I hate arguments like this, appealing to some magical distinct codex of grammatical law as if language isn't messy and largely evolutionarily in nature, and highly dependent upon the current socially agreed-upon context.
Like when pedantics get angry about the misuse of "begging the question". If the majority of readers understand the phrase to mean "demands that we ask the question", then that's what it effectively means.
I put up a donation link (before GitHub sponsors was introduced) on a repo that had 5k+ stars. Got just one recurring donation (about $1 a month). This wasn't a s/w tool though (tutorials for CLI text processing).
Later, I switched to creating books out of such tutorials. I gave them away for free during launch weeks (but readers could still pay if they wish) and this model worked so well that selling programming ebooks is now my primary source of income.
I used to work in a semiconductor industry before. My earnings this year is 25% of what I used to earn 8 years back (literally, not adjusted for inflation). However, this is still more than enough to pay my bills ;)
I was part of a team responsible for design and verification of DSP (digital signal processing) chips. ASIC part of the username refers to both "application-specific integrated circuit" and my college friend circle.
It sounded bad, but how much donations that you'll receive don't actually always link to star counts. Stars on GitHub is more like "how many people added this project to their bookmark" than anything else.
That said, as how things goes, there are "high value" projects as well as "low value" ones. If you want to make money out of your open source project, target those "high value" use cases might help. Some fields just don't make a lot's of money even if you tried really hard.
Imagine for a moment though, if GitHub stars could pay your rent.
Imagine a corporation spends money on an experiment where they purchase some luxury units of a fancy apartment building, and then rent was decided based on GitHub stars. You must collect a certain number of GitHub stars each month to satisfy rent or you get evicted. I wonder what kind of projects would come out of this.
Also the distribution of stars is... weird. I've got a repo with 24k stars (which is still enough for top 500 on github) which took minimal effort and no maintenance - definitely lower than a lot of large software projects which deserve lots of money. Like, I'm next to pipenv and vagrant and making any money distribution based on that would be absurd.
I agree. I recently starting contributing to an open source project, really enjoy the feeling of contributing and interacting with other passionate contributors and maintainers.
I don't really get to interact, except with a few users. For me, it's the idea that u actually built something useful, it's my own idea, and I have full ownership of it.
At my day job, the expectation are vague, I have no real power, the people who do can't answer my questions intelligently, and at the end it's like I did some miniscule part of a system that works just OK, but not up to my standards.
I have been thinking about closing my Github account and moving all my code to gitweb on one of my personal domains. I'm tired of the social/popularity contest aspect of Github and just want to write and publish code that I find interesting. I also want more control and I don't want my code used for AI research like co pilot. I thought about trying source hut, or something similar, but I feel it will end-up just like github once it gets more users.
Has anyone else setup a simple gitweb server on a personal domain? If so, how did it turn out?
how does another platform help you evade copilot? wouldn’t a “lower” platform have to pursue legal routes that are very unpalatable for those lacking deep pockets and legal expertise?
Anyone may purchase a domain name from a registrar (such as 'example.com'). That is not a 'lower platform'. It's just a domain name. Sure, it's not as popular as 'github.com' but in every other way (in the DNS) it is equal. And unlike github.com, you have full control of that domain and its DNS records.
There are no unique legal issues with regard to buying a domain name and writing and publishing source code on that domain. Using 'github.com' to host your source code does not give you more legal rights or protections. Copyright is copyright and a license is a license no matter where you publish it.
You should not be afraid to buy a domain, write source code and publish it there. It's not illegal to do that and you are not at more risk (although these big central social platforms would like for you to believe that).
The unpleasant truth is that you won't "escape" copilot; if anything is going to be done about that, it's more or less a legal issue.
That all said, the author of SourceHut seems really principled in regards to what they're building. If I was going to bet money on one person not ending up like GitHub (and one platform not ending up like GitHub), I'd probably bet on them.
I kicked the wheels on it recently and was really impressed, though I'm unsure if I'll use it full time yet - for all it does well (kind of putting git back to what it should be), it does draw a line in the sand where I'm not sure I'd draw it. Something like Gitea might be another option since it can provide a familiar enough interface to drive-by contributors.
In truth, I wish Gitea had support for git-send-email similar to SourceHut. Feels like it'd be the best of both worlds.
I use Fossil for self hosting code on my own domain, it's running on a fan-less PC with daily backups to the cloud using restic. It's just so nice, no social pressure and it works for me when the internet is down. I am currently in the process of setting up Concourse CI, it's a really nice config driven ci system.
Also, it doesn't have to be a "one or the other" thing, you can use both GitHub and self hosted for different things. That's what I do, GitHub is for work and things I want to be social, and my own hosting is for private code or code that I want to share in a "take it or leave it" kinda way without any of the social stuff.
I highly recommend hosting your own git/fossil/etc... system for yourself. Think of it like your own little place that you can setup exactly as you like.
I have done exactly this, after being fed up with GitHub. Surprising no one, if you set out to build the “social media but for code”, that’s what you get.
I’m using a combination of cgit, Gitolite and Nginx. Once set up, it’s easy to use and rock solid. Gitolite configures through a Git repository. I’m not going back.
Regarding your GitHub account, I suggest to simply replace the content you moved with a notice to the new URL and then archiving the repo, making interaction impossible. Even if you’re looking at deleting everything, maybe keep the account itself around, it’s free and you may need it later.
I sometimes use github search to double-check if someone has worked on a problem before startin myself. Even when the repo is abandonned, it sometimes gives a good starting point. GitHub often tells me about repos I didn't find on search engines.
I'd say go for it, but the discoverability aspect is important.
I also follow friends and sometimes find interesting projects through their stars.
This is, increasingly, one of the only things I find myself locked into GitHub for: if I'm working in a space that's sufficiently "old" (e.g, macOS APIs), I generally cannot get Google to produce anything useful anymore and end up having to comb through various GitHub repositories. It's maddening.
No other code search engine comes close anymore, unfortunately.
May I ask: let's say I am Joe Schmoe, an individual, not a corporation. But I have a particular need for coding done in, say, AutoHotKey or as an Outlook macro. I wish to pay someone for this small coding project. What is the best forum to do this exchange?
I'm assuming this question would be on-topic to this thread because it is essentially, "If someone DOES want to help you to pay your rent, or at least for a week's worth of coffee, where's the best place for that?"
It is definitely not easy to pay your rent with open source and the money is likely not as good, but there are a lot of folks who do. Some resources for different ways to do that:
250 comments
[ 3.8 ms ] story [ 276 ms ] threadbuy-me-a-coffee™
Jokes aside, I've never minded paying for things, and never could be bothered doing the open source / paid version model that the author spoke of.
I hope you succeed, of course. But since I have no good idea what your app is, except "a browser for developers" from the blog text, there is really no chance that I would ever search for this app, hear about it thru word of mouth, or eanything really that would make me end up testing your app.
Here's some other ways you could have tried to approach the situation:
- stop providing compiles, while selling access to the compiles on patreon or something. this way you can keep engagement from other developers and stay FOSS.
- offer commercial services around your app
Given that, their income seems about right. Only a tiny fraction of (potential) users are typically willing to pay anything.
A useful free and open source project garners GitHub stars and general recognition because it is useful, but also because it is free. The stars are the social compensation in this case. The free nature of the software is essential to that relationship.
[1] https://en.m.wikipedia.org/wiki/Free_software
[1] https://lists.gnu.org/archive/html/libreplanet-discuss/2016-...
Just think about what it means to be top mod of a cities subreddit. You can trivially just delete conversations you don’t like.
Moderators have powers, use power and are often not at liberty to reveal all what went into their decisions. Moderation on any scale is however a team effort and is then subject to scrutiny, discussion and review. Power tripping moderators will be removed by the team and in communities with a sole moderator who is on a power trip it will not thrive.
Where is this mysterious subreddit, where such incredible, almost magical, things happen? Are we really talking about reddit here?
The Internet is built on a lot of great people doing things for free. That doesn't have to be a bad thing if you are okay with it. But always make sure you feel good about what you are doing. If you get enjoyment or a sense of accomplishment (to quote EA) out of it then it's no worse than playing a video game or watching a tv show.
Larger boards are like organization with promotions. Abuse of power won‘t earn you one. There are steering structures. Sometime one has to adjust what moderators do and have a discussion on what happened. Occasionally one has to kick a moderator out.
If you don‘t know why people help strangers then this may be worth a thing to investigate for you.
However it makes you an especially visible member of that community, especially to its worst elements. The constant hostility and eventually the harrassment made me step down.
Now I watch other moderators go through the same motions. People are absolutely vile to them, all over a tiny internet forum.
The problem with mods is that some of them behave badly enough and go on power trips banning people for their own enjoyment and making tantrums, thus giving a bad rep to the whole category, including those who are actually good people with sane principles.
webarchive link: https://web.archive.org/web/20221110001855/https://kitze.io/...
The best part is when corporations get involved. A company will absolutely get something for free if it can, but if it has to pay, it'll pay a lot more than the absolute minimum, for PR reasons.
[0]: https://github.com/Fody/Home/blob/master/pages/licensing-pat...
Maybe I’m misunderstanding but does this mean that you cannot submit a bug report unless you donate to them?
You didn't pay? Well, that's just, like, your bug report, man...
Essentially it boils down to: you cared enough to submit a bug report? Then you should also care enough to donate.
That is true of any open source project.
And presumably the maintainers are not bound in any way to not re-open an especially good/important bug. It just makes makes non-patron support opt-in, instead of opt-out.
This is about managing expectations. And generally in the modern world, if you want someone to fix something for you, you pay them.
I'm sure this model works well for an established project like Fody that's already quite highly polished, but I'd be pretty sad if all (or even a significant subset) of open source adopted this model.
I'd definitely be interested to hear any counter-arguments to this though. Are there any avenues for individuals to contribute for free, if they aren't using it for profit?
The distribution of something already made is free. Supporting, understanding your issue, developing a fix and releasing it…all of that takes a real person’s time.
As a contractor, you learn very quickly that people will ask for anything if it doesn’t cost them anything. There are a lot of people happy to take advantage of you if you let them.
I like seeing a good model to get OSS devs paid.
Personally, if I submit a bug report or PR to an OSS project (which admittedly doesn't happen very often), it's almost always because I think the time I've spent investigating the bug/feature could benefit other users of the project.
For my use cases, it's generally much faster and easier (at least in the short term) to just fork a project and make whatever change I need locally, than to wait for it to go through review/merge/release in the original project.
Another commenter has pointed out that they make exceptions for certain types of contributions though, which I guess would help with this.
You realize that my dependency stack contains about 2500 dependencies right? If they all follow this model I’m looking at $90k/year just to contribute to a project.
Also, the business model is paying a subscription for the right to submit a pull request. Sure, you could wait until you are about to make the PR to buy the subscription, but that's a pain of its own.
Their point here is that this isn't a scalable business model. That's the assertion that started this whole comment thread.
Dependency management has gotten off the rails.
I think most businesses could afford it
That is amazing: when I was younger, sharing code was a goal, but absolutely nothing could prepare me for your world. Previously I have had the luck to be able to rewrite a lot from scratch, removing most runtime dependencies, although definitely not replacing build dependencies.
I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?
Modern devs don't care. They just install whatever, let it pull in 1000s of other packages, and continue on their merry way.
Meanwhile, a package you use today, can root your stuff tomorrow. That is, next update and bam! Package was sold to Evil Entity, or just the dev decides to rm your drive based upon geo location.
I get paid a lot to cleanup much of this mess, and while tools such as composer and node.js are useful, they are a horrible, horrible security risks.
If you use node or composer, be prepared for dozens of updates weekly. Each update risk laden, and feature and security fixes all mashed into one.
On a large project, you'd need multiple devs, just to audit all the change.
But as you will soon see, there will be all sorts of $reasons given, which all lack understanding of how traditional Linux distros handle updates, and boil down to "not my problem" or "someome else magically makes it safe!"
Have an unobvious copyright condition, get your code in thousands of projects, then spider the internet looking for companies that use your code, and charge them a $1000 “licensing fee”.
Or change the copyright in v1.1.2.2 and wait until everyone updates, and do the same thing.
> Modern devs don't care
I think the “modern” is superfluous and vaguely insulting: security isn’t/wasn’t cared about by most old-skool developers either!
I think this may be a case where because you have a bunch of freedoms, you feel like you should have more.
I say this to re-assure you, not critisize you.
Open Source, and Free Software, are very clear on the 4 freedoms you enjoy. You can use, modify, distribute etc.
But it's not a 2-way street. You have no rights about what goes back into the project, the author is under no obligation to receive code contributions, no obligation to add features, fix bugs, or anything like that.
Of course lots of projects actively seek out contributions, but it's certainly not a requirement - nor (IMO) should it be.
Coversely open source has struggled to find viable financial models. This sounds like a success story and we should look long and hard at any successful financial model.
So, I don't think you should feel unsure. If you want to contribute then chip in some loot. If it means the project becomes sustainable you are the big winner.
But most of all, I think, be careful of adding "more freedoms" to your understanding of OS and FS, when they don't exist.
From a user point of view, project first is the only thing that matters. There is an instinctive resistance to anything that gets in the way. On the other hand users generally don't care about the project authors getting paid or not.
From the author side, getting paid is often a goal. If that means limiting the community to paying users, then so be it. From their perspective they are offering value, and they choose to spend their time focused on users who are paying.
In other words they need your money, not your code suggestions. They can code, but code doesn't pay rent.
As you say, others can choose to silo their changes, and not post them back, that is their right, and indeed likely happens anyway.
To take an exaggerated example, if I tried to use this model with any of my small OSS side projects, the only result would be that no one would contribute. This model means that the development of the project is going to be almost entirely driven by:
a) The original maintainers of the project (who will rightfully get bored of maintaining it at some point), and
b) The handful of companies that have financial interest in a certain bug/feature.
Again, that's probably fine for projects like Fody, but certainly not all of OSS.
> This process will depend on the issue quality, and the impact on the larger user base.
So, if I understand correctly, they won't automatically close issues if you aren't a subscriber, but the bar for the quality to keep it open is probably significantly higher.
I don't think that's a bad model. Although, I don' think it would scale well to every open source project having it's own subscription stream. But maybe if there were companies that maintained collections of projects?
That's essentially someone helping your paid customers to have better product for free.
I've been struggling with this issue with my project. It's a completed project, no scope creep, no bugs, just occasional update once every 6 months or so. The docs are complete and detailed so nobody needs extra help; no one will pay for support
At the same time, I know for a fact that if the project was buggy or had gaps in the documentation, nobody would use it; they would use an alternative solution from a big corporation.
The level of competition is so intense that there is no room for profit, no room for missing documentation and no room for bugs on my end. Competing products are backed by a big name brand tech corporations; so they can have bugs and gaps in the documentation and users will forgive them.
Branding is extremely powerful. Once people trust a brand name, they will ignore reality. If you don't have a brand name, you need to be 10x better to be perceived as the same quality.
It sounds to me like you have a solid project, and some number of users. With good docs. Which is great (we'll done.)
I'm assuming you want to monetize it? That seems to be the logical next step. Alas I'm not going to be very comforting with the next bit.
A) the time to think about monetization is when you start the project, not when it's done. Obviously a lot of projects get done for reasons other than money, and when you started you may have had other reasons. That's fine. But monetizing after-the-fact is a very difficult, dare I say "unsolved" problem.
B) this is going to sting, but most successful money-earning products have nothing to do with the code, beyond that it exists. A "business" requires more than "product" - a lot more. Marketing, sales, revenue, administration and so on. All of this is expensive, hence the need to have a business plan (ie, how does this thing make money?) before you start.
As developers we have a code-first mindset. But we try and compete with companies that have a business-first mindset. Companies are winning.
The fact that your project is complete, that it is solid is fantastic. Well done for that. However turning it into a business may be impossible, or expensive. That's OK. Celebrate what is is, don't pine for what isn't.
If nothing else you've learned the difference between a code project, and a business, and if you internalise that then you will have gained something of high value.
What is missing is recognition for those small projects without marketing or branding that are better and more bug-free than corporate projects.
Money is not needed, just recognition.
Big companies known for abandoning projects have a bad brand in that regard (although their brand might be good in other areas).
How is that a more ethical, straightforward, or profitable business model than just GPLing the project and offering proprietary licensing?
Releasing code under a permissive license, then calling people dishonest when they use it according to the license but not the authors’ desires, seems silly and inefficient.
Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and you reject it because you want me to pay you first, I'm dropping your software without a second thought.
You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
If someone is going to just close these questions, then I will drop them as it’s not open source I want to be a part of.
I am okay with paying for software. not okay with paying to find out my feature request will get denied
The requirement to be a member of a collective is a filter. For popular projects it will likely do more good than bad. For niche projects, it might be worse than no filter.
They were explicitly talking about PR for a bug, not unwanted feature.
Yeah, sure, there is occasionally low quality bug fix that's problematic issue (bug should be fix but the code to fix it is garbage and nobody wants it) but I think that's rarer problem
Wouldn't you first check the license and contributor agreement before doing such a thing, even on random FLOSS projects?
Unless they are not disclosing their policy in the contributor agreement or the license, I don't really see a problem here.
BTW, the reason I mention sending PRs for bugs I encounter is that, when I do encounter a bug I don't immediately file a GH issue and make it the maintainers' problem. Instead I act upon it just like the maintainer would, by checking the source to figure out why the bug is happening, `git blame` etc to see what commit added that code, whether the issue I'm encountering was already identified or discussed when that code was committed, and so on. So as a result of doing these things I often end up either knowing my issue is by design and that I was doing something wrong, or end up having enough knowledge to be able to construct a bugfix myself.
Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
Pull requests take work to review and test. You shouldn't take that for granted and assume everything will be merged for free.
If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
Nonsense. You think signing yourself up to maintain a patched version of someone else's code for eternity is better than using someone else's code? You have to sign up for upstream CVEs, keep updating the upstream base and rebasing your patches on top.
>Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
False dichotomy. A library is measured in various dimensions - how well-maintained it is, what features it has, OS / hardware dependencies, performance, etc. Something that is better in one dimension might be worse in another dimension, so that there's no single objectively better library.
>If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
I have my own work to do, not maintain forks of other people's code.
> It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging.
Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
Fine. But if my code is useful, and it ends up convincing more users to become Patrons, will I get any financial gratification from the Fody maintainers? Or are any profits from this contribution going solely to the maintainers?
In your average open source project, backing it is separate from using it and contributing code to it. My contribution would therefore benefit all people, including those who cannot pay. But the Fody maintainers consider them to be freeloaders and unwelcome people, so I have reservations about contributing and what the benefit from my contribution would be to others. I'm not working for free for a for-profit entity.
No, I really don't.
https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.
https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.
https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.
https://gitlab.alpinelinux.org/alpine/aports/-/merge_request... - I noticed that gnome-passwordsafe crashes some times, debugged it to discover that it was missing a dependency, sent a PR to the distro package to update the dependencies.
etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.
Also, to be clear, there is nothing special or unique about what I do. All large community projects where the users greatly outnumber the developers continue to work because of PRs like these from their users.
re: https://news.ycombinator.com/item?id=33529742
(Had not heard of OpenCollective before yesterday so intrigued to see it come up twice)
Why not just have the public facing project be a fork of a private, access protected project where bug tracking and PRs are handled, that only patrons can access?
For some reason, saying "only patrons can access our development repo" seems perfectly reasonable, but saying "we'll close your bug report if you don't pay us" feels a bit grumpy.
From a business perspective that's basically a rounding error and nothing compared to what you can do with the conventional approach of selling consulting/support or, heaven forbid, your own proprietary solution.
So in what sense is this the best model? Has anyone used it to generate $100,000 in annual revenue, let alone say $10M+? More profitable model = more hiring developers to improve the software...!
If you want to start a business it can definitely have an open-source element to it, but that's just it. The open-source part is just one piece to a business and you better be aware of all the other pieces that need to be done in order to make money which aren't always engineering/programming related. EG: marketing, sales, consulting, fundraising, accounting, etc...
A common approach that people do now is create the open source offering then run it as a service where they can charge a premium for the support and leg work for hosting it. See: mongodb or elasticsearch or influxdb.
I haven't found many pure open source solutions where all they do is make the software better all day and ignore all the elements of business growth needed. Maybe the Linux foundation is a good counter example but I don't think there is a clear path to be paid for just contributing solely to open-source while neglecting other business elements.
This is a poor choice for a donation-driven project because it allows easy proprietization. It also does not protect from patents, tivoization and so on.
GPLv3 would be a better choice.
I don't know enough about the resulting system, but this sounds quite silly and contra-productive. Issues often hint at important flaws. If the community is not open (Ha!) to outsiders notifying them of important flaws, then that is a recipe for bad software. Some people might go there and start asking for features, instead of describing issues (although even that can be valuable input), but in my experience people are more often reporting bugs or asking how to do something, because it is not well described in the docs, or the docs are not as visible as they should be, or probably many other good reasons. Closing ones door to these valuable inputs can only result in worse software.
We are not talking about the same kind of issues or people. Aside from the strawman:
People creating an issue with all the detail are already investing time into reporting an aspect of your project. Immediately closing the issues is like giving them a middle finger, for investing their time, trying to help the project.
Sometimes, when I have a problem with some tool being buggy, I consider opening an issue, but sometimes I don't do it, because I know it would be time-consuming. However, when I open an issue, I usually try to provide all required information and maybe even an example to reproduce the issue. I invest time to make it easy for the maintainers to see the actual issue. If they closed that issue immediately and wasted my time like that, I would be very careful to ever invest time again into anything those people create.
FOSS is not about making money. In fact, it's antithetical to making money.
Value extraction is the province of closed source/user hostile software, by nature.
FOSS is great for doing "common good" code that everyone uses and many sides want to push forward, but not exactly easy to monetize if you're just a dev doing a thing.
The first name that came to your mind was Torvalds - hardly a random.
And that is the kernel. There are also companies like Red Hat and Canonical that make money through their work (more) in the userland. The people that they hire all make money from FOSS.
Edit: For example, look at the “Most active 5.10 employers” list here:
https://lwn.net/Articles/839772/
> When was the last time you chose a value above 1$
> you're a saint for choosing 2.5$
> OMFG THIS SHIRT IS 20$
For the record: the dollar sign comes before the number. I'll take the downvotes, I just can't stand it. I did read the article, and my heart goes out to the author.
> In the United States, Mexico, Australia, Argentina, New Zealand, Hong Kong, Pacific Island nations, and English-speaking Canada, the sign is written before the number ("$5"), even though the word is written or spoken after it ("five dollars", "cinco pesos"). In French-speaking Canada, exceptionally, the dollar symbol usually appears after the number, e.g., "5$".
https://en.wikipedia.org/wiki/Dollar_sign#Prefix_or_suffix
The linked article appears to be talking about U.S. dollars, and all evidence points to it being written in English, so I don't believe the regional usage is relevant.
It's hard to argue what the accepted usage will be in future generations, but using the dollar sign as a suffix does not appear to have become accepted by any institutions I'm aware of at the moment. Distinguishing a simple mistake from a visionary act of linguistic prophecy is beyond my capabilities.
If you can point me at a reference that makes a good case that the linked article is the accepted usage, I'd be obliged.
Regional: Philippines (personal experience) and many other countries write currency symbol following the number[1]
Generational: starting to show up in texting culture[2]
Having experience with languages evolving due to technology, including a few Filipino dialects, I've observed people adopting new conventions in spite of older generational mores is nothing new. Happens all the time. And as a person gets more experience with places that have different conventions, they typically let go of the provincial views that their learned way is the only way. The dollar sign is not the only chrrency.
Does a US dollar sign after a number look right to me? No, because my grammar teacher taught me differently. But my native French boss flipped it all the time and nothing of communication value was lost.
[0] https://linguaholic.com/linguablog/dollar-sign-before-or-aft...
[1] https://en.m.wikipedia.org/wiki/Euro_sign#Use
[2] texting and Text-to-Speech capture of written language.
Like when pedantics get angry about the misuse of "begging the question". If the majority of readers understand the phrase to mean "demands that we ask the question", then that's what it effectively means.
Later, I switched to creating books out of such tutorials. I gave them away for free during launch weeks (but readers could still pay if they wish) and this model worked so well that selling programming ebooks is now my primary source of income.
I was part of a team responsible for design and verification of DSP (digital signal processing) chips. ASIC part of the username refers to both "application-specific integrated circuit" and my college friend circle.
That said, as how things goes, there are "high value" projects as well as "low value" ones. If you want to make money out of your open source project, target those "high value" use cases might help. Some fields just don't make a lot's of money even if you tried really hard.
Imagine a corporation spends money on an experiment where they purchase some luxury units of a fancy apartment building, and then rent was decided based on GitHub stars. You must collect a certain number of GitHub stars each month to satisfy rent or you get evicted. I wonder what kind of projects would come out of this.
No. But they'll give me the satisfaction my day job never will.
At my day job, the expectation are vague, I have no real power, the people who do can't answer my questions intelligently, and at the end it's like I did some miniscule part of a system that works just OK, but not up to my standards.
Has anyone else setup a simple gitweb server on a personal domain? If so, how did it turn out?
There are no unique legal issues with regard to buying a domain name and writing and publishing source code on that domain. Using 'github.com' to host your source code does not give you more legal rights or protections. Copyright is copyright and a license is a license no matter where you publish it.
You should not be afraid to buy a domain, write source code and publish it there. It's not illegal to do that and you are not at more risk (although these big central social platforms would like for you to believe that).
That all said, the author of SourceHut seems really principled in regards to what they're building. If I was going to bet money on one person not ending up like GitHub (and one platform not ending up like GitHub), I'd probably bet on them.
I kicked the wheels on it recently and was really impressed, though I'm unsure if I'll use it full time yet - for all it does well (kind of putting git back to what it should be), it does draw a line in the sand where I'm not sure I'd draw it. Something like Gitea might be another option since it can provide a familiar enough interface to drive-by contributors.
In truth, I wish Gitea had support for git-send-email similar to SourceHut. Feels like it'd be the best of both worlds.
Also, it doesn't have to be a "one or the other" thing, you can use both GitHub and self hosted for different things. That's what I do, GitHub is for work and things I want to be social, and my own hosting is for private code or code that I want to share in a "take it or leave it" kinda way without any of the social stuff.
I highly recommend hosting your own git/fossil/etc... system for yourself. Think of it like your own little place that you can setup exactly as you like.
I’m using a combination of cgit, Gitolite and Nginx. Once set up, it’s easy to use and rock solid. Gitolite configures through a Git repository. I’m not going back.
About 14 days ago, on a post about Gitea incorporating, I shared my writeup of the install in case you’re interested: https://news.ycombinator.com/item?id=33341191
Regarding your GitHub account, I suggest to simply replace the content you moved with a notice to the new URL and then archiving the repo, making interaction impossible. Even if you’re looking at deleting everything, maybe keep the account itself around, it’s free and you may need it later.
I'd say go for it, but the discoverability aspect is important. I also follow friends and sometimes find interesting projects through their stars.
No other code search engine comes close anymore, unfortunately.
Do you know if there's a way to submit something to this to spider (e.g a Gitea instance)?
Don't you also want people to read the code you publish?
Not that GitHub is the only relevant venue, but still.
I'm assuming this question would be on-topic to this thread because it is essentially, "If someone DOES want to help you to pay your rent, or at least for a week's worth of coffee, where's the best place for that?"
https://github.com/fossjobs/fossjobs/wiki/resources
The github stars is quite useful to break into big tech as well. But the value of it probably stops there.