This is all pretty ideal and I think these outcomes are more likely if the project has a substantial base.
Comparatively I was trying to contribute to another FOSS project only to get push back. I started contributing to the docs to build the package which were way out of date. The project switched from qmake to cmake. The project did not have a correctly working cmake setup so I assisted with that. Every time I contributed the maintainers would check my PR then ping another maintainer who was supposedly working on the specific issues. Eventually I managed to get some docs and code merged but after that the maintainers returned harder to blocking my PR’s with their own work which they happily merged in. They would not update my PR that they had already gone in and solved the problem, I had to repull and figure it out myself, which left me with open PRs/tickets just lingering in the space. They would happily clarify my questions with obscure non-revealing conversation about their project. Eventually I gave up.
Similarly I have tried to contribute to things like KDE in the past as well and been met with similar walls on contributing. Some developer somewhere is in charge of a FOSS project as a hobby and only really cares about their use cases or providing a simple demo app or rewriting an old app for their needs because the old app was too complicated or probably run by another hobbyist maintainer. This leads to opening tickets and looking for ways to contribute or discuss implementation with little to no response. Or in the case of KDE, having your ticket closed and shifted over to their bug system which requires rediscussion and retriaging.
At some point you just lose momentum and interest trying to push a project along due to the sheer uneventfulness and refocusing of it all.
I think we need fewer hobbyist project owners and more hobbyist project managers.
Not to be mean, just to provide a different perspective: having an open source repo doesn't automatically mean I want to deal with every pull request in a timely manner, merge docs cleanups that I don't even like, and especially reviewing and merging features that I don't want. It's true for personal and probably for professional projects, too.
Open source means what's in the license, everything else is just us setting expectations for others that they don't want to our can't meet.
For example, I make my projects open source because I don't care if anyone else uses my code, so why not.
Okay well I never indicated any sort of urgency for my contributions, just that they be considered at all, not ignored then reimplemented because the maintainer has trust issues. Projects I have contributed to in the past aren’t personal projects. They are public facing software that is expecting to be used by the public. The first one I mentioned was a UI library that made me sign a contributors agreement, others have been desktop applications and desktop vpn management code.
If you have no intent of accepting contributions you should put that in your README.md or CONTRIBUTING.md. Or even indicate the frequency at which you’re able to consider contributions.
I still believe that open source is about what's in the license, and everything else is just us putting expectations on others. Understanding this made me less angry with the world.
And why do I need to put any of these things to anywhere, why do I need to explicitly opt out? And making promises about the frequency at which I'm considering contributions, promises I'll most likely break at some point, just sounds like a perfect way to introduce anxiety into my hobby project.
You don’t have to do anything, that is perfectly clear. Just don’t expect to be successful or be taken seriously if your project is expected to be used by everyone.
I think you might be confusing my intent about a hobby project vs project ownership as a hobby. This article and thread are mainly about the latter.
When random person from the internet opens PR on my project it is not trust issues to look at it from every angle or not considering it because you don’t have time for that.
It is perfectly reasonable not to trust random strangers on the internet.
> Or even indicate the frequency at which you’re able to consider contributions.
Since most things are on GitHub these days, implementing some PR-related analytics for each repo would be nice. This would give you an rough estimate on what to expect and make an informed decision on how much time you are willing to spend.
I believe the repo commit frequency will tell you this (sort of) combined with reviewing pr closed history. However that doesn’t account for the inner circle issue.
The main intent of the information though is to indicate process for good natured contributions, however basic as to minimize time waste for the maintainer.
I had similar frustrations with a well-known deep-learning framework.
I'd get well-vetted PR's for the build system, CI system, etc. committed. Only to have them later undone, without discussion, by people in the inner circle.
It doesn't take many experiences like that to lose all motivation.
I think some open-source projects deceive themselves (and therefore, outsiders) about their contribution processes.
Nothing stifles progress and contribution more than having a maintainer take your effort and implement it themselves or carelessly merge your work in without review only to have it reverted for not contributing code correctly. For a lot of FOSS the review process is that the maintainer does it themselves when they feel like it.
And you just know the discussion by that inner circle that could have happened during code review is happening in some private email or chat app somewhere away from public eyes.
I love Rich! Using it for tree_plus and other projects, and it’s beautiful and hackable. Great Python package for terminal visuals. Definitely recommend it if you have a Python CLI, can really improve readability and visual niceties.
> Additionally, I would work on a cloud service using both those projects which at some point would become a business.
> Now this was a good plan. The money from GitHub sponsors which I had previously been donating to charity would take the sting out of not having an income for a while. While far from a salary (where I live), at around $1000 a month it would help pay a few bills.
> I have far more confidence in that vision now that I have raised seed funding. Predicated on that cloud service, I have enough funding to hire a few developers to work on it with me. Last month I was an unemployed code monkey, today I am a Founder / CEO of Textualize. Go figure.
Good find! Getting seed funding to try and monetize a bunch of MIT libraries using a "cloud service". Wild. Wonder if OP was always 100% dedicated to FOSS for 503 days or if they worked on the "cloud service"...
Contributing to OSS is a hobby, not a job. You explicitly work for free on purpose. Whether or not you’re able to pay your bills is unrelated to the OSS contribution, it’s very clear that you’re not going to get paid for writing code that you’re giving away for free.
An example of one person being employed and contributing to open source as part of his job is not a refutation of the statement. You don’t have to read anything to know that, just use logic.
To provide a counter-example you’d need to reference an open-source project that makes money selling the source code which, hopefully obviously, doesn’t exist, by definition
Comparatively I was trying to contribute to another FOSS project only to get push back. I started contributing to the docs to build the package which were way out of date. The project switched from qmake to cmake. The project did not have a correctly working cmake setup so I assisted with that. Every time I contributed the maintainers would check my PR then ping another maintainer who was supposedly working on the specific issues. Eventually I managed to get some docs and code merged but after that the maintainers returned harder to blocking my PR’s with their own work which they happily merged in. They would not update my PR that they had already gone in and solved the problem, I had to repull and figure it out myself, which left me with open PRs/tickets just lingering in the space. They would happily clarify my questions with obscure non-revealing conversation about their project. Eventually I gave up.
Similarly I have tried to contribute to things like KDE in the past as well and been met with similar walls on contributing. Some developer somewhere is in charge of a FOSS project as a hobby and only really cares about their use cases or providing a simple demo app or rewriting an old app for their needs because the old app was too complicated or probably run by another hobbyist maintainer. This leads to opening tickets and looking for ways to contribute or discuss implementation with little to no response. Or in the case of KDE, having your ticket closed and shifted over to their bug system which requires rediscussion and retriaging.
At some point you just lose momentum and interest trying to push a project along due to the sheer uneventfulness and refocusing of it all.
I think we need fewer hobbyist project owners and more hobbyist project managers.