> So, to say, I usually pick Quality and Velocity.
Velocity is what you choose when you have a runway. The most successful open source projects like Emacs and GNU Make have been sitting around for about 40 years now, being slowly and steadily maintained by their owners. I've been working on a C library of my own for the past 6 years and it's only started to gain traction in recent months. If I was doing it as a startup my project would have been laid to rest in a charnel house long ago. But since it's open source, the only thing it's really cost me is time.
I'm also wondering to what extent does the stack or framework force you into prioritizing velocity. For example, I've never worked with Vue but if it's anything like React, I can imagine that a library could quickly become "outdated" after a year or so unless you constantly keep the dependencies up to date and maybe even change any dependency that becomes deprecated.
GitHub makes this unnecessarily worse by refusing to let you disable Pull Requests like one can disable the other social features (Wiki etc) of a repository: https://github.com/dear-github/dear-github/issues/84
I'm fairly sure that it's possible to be a maintainer and not have to bend over backwards for some imagined "community". For the most part you can just accept patches, make decisions regarding the scope of the project and help with development on a best-effort basis.
The default reply to a feature request should be "patches are welcome". If the software is useful, people won't hesitate to contribute fixes.
> I'm fairly sure that it's possible to be a maintainer and not have to bend over backwards for some imagined "community"
In recent years I’ve noticed more than a couple projects that have been aggressive about building a community, but uninterested in accepting patches or fixing bugs themselves. It’s frustrating when the GitHub project has prominent links to join their Discord and the author is constantly pushing their project on social media, but then you open the Issues and see 2-3 year old simple issues with multiple pull requests from people desperate to fix it, but the maintainers aren’t actually interested in anything other than collecting more GitHub stars and expanding their community.
Yeah I agree with this. You can only do want you can do and what you want to do. If there's more than you can or want to do - either pass it over to someone who wants to do it or don't do it.
If people really want something beyond you means / energy they can submit a PR for it or fork your project.
If you're tired of replying to everyone simply have a bot close duplicate issues and let people discuss among themselves in a forum to provide peer assistance.
If its your baby and while you want to open source it you don't have any energy or desire to provide support/maintenance - just lock creating issues all together (not ideal, but if people have a community forum they'll be fine).
If you're the only person that can review/fix/maintain something then you're part of the problem, not the solution and you might need to hand over to a wider audience or flat out remove yourself as a maintainer.
"Yeah I agree with this. You can only do want you can do and what you want to do"
"If you're the only person that can review/fix/maintain something then you're part of the problem, not the solution and you might need to hand over to a wider audience or flat out remove yourself as a maintainer."
How do those 2 parts go together?
Because the first part is correct, I don't need to do anything. But if I open source something, meaning making a gift to the world, I totally can choose to maintain with as little effort as I want to. I also don't have to provide a forum - that is a project in itself and comes with legal liabilities.
> If you're the only person that can review/fix/maintain something then you're part of the problem, not the solution and you might need to hand over to a wider audience or flat out remove yourself as a maintainer.
There's really no need for that. An active fork will eventually show up if people care enough. If it keeps improving, it becomes the new upstream and the original gets left behind. That's the way it should be.
That can get tiresome quite quickly. Sometimes you do submit patches but they still don't give you the time of day. Sometimes they don't actually want your code. Sometimes they only accept code from some inner circle you're not part of. You might end up wasting a lot of time only to hit these walls and end up with zero results to show for your efforts. Then one day you might discover that the maintainer committed some suspiciously similar feature to the repository all by himself.
People gotta stop acting like submitting code somehow elevates us above simple users. It really doesn't.
Yeah of course, if someone has sent a patch I would consider it a duty of the maintainer to review it, maybe rework a little if needed and commit with the necessary attribution. But I don't think it's the end of the world if a patch isn't accepted by the upstream. Assuming the pace of development isn't too fast it is not too much effort to maintain a friendly fork and occasionally rebase it.
There is a fundamental difference between the duties of a maintainer and a developer. Just because some people are both doesn't mean they are the same thing.
Of course if your patch breaks the entirety of the testsuite (it has happened to me) and you get angry when you get asked to fix it… well not a big problem to lose such a contributor.
Given the headline, there are some points not raised, which I'd love the poster to cover.
A) income. A chunk of mental health comes from the security of a steady income stream. To what degree does the poster have this?
B) environment? Another chunk of mental health comes from interacting with others. Ideally in person, but online is also good. Human contact, meet ups, conferences, are all good ways to feel connected and appreciated.
C) Content? Do you feel like you're doing enough? Do you feel like your projects are meaningful? Are you content with the users you have? My own mental health benefited from becoming content with my place, my work, my reach. I measure my reach in hundreds not millions, and for me that's OK.
Mental health is important, Open Source or not. But the above 3 factors seem to me to be the big hurdles for those in that space particularly.
Regarding A, one point I've seen raised about open source, specially the idea about checking someone's github activity as part of a hiring process, is that making open source contributions, or more specifically, contributing for free, is a privilege the poor can not afford.
It's ironic, but exactly the people who benefit from free software wouldn't spend their time making free software because they need money to eat.
If newer generations are less willing to sacrifice mental health for open source work could we soon enter an era of far less ambitious open source projects?
> This blog you are reading took me roughly a week to write (that’s a pretty long time for me), fragmented into multiple sessions.
Writing is hard. A good essay takes days if not weeks (sometimes months) of iterations.
The author’s blog post is well written and a week of effort is fair, IMO.
How does one become a full time open source dev? do they get paid? who pays them? I mean it makes sense that if lots of people/companies depend on the project that they SHOULD get paid.
My first job was developing and maintaining a streaming system based on Apache Flink. Thus, it's normal to me that a "full-time opensource developer" can get paid.
Of course, there are some in-house tasks. But still, I spent a lot of time participating in the upstream community and became a committer after about one year's contribution.
That said, after I changed my job, my engagement decreased considerably. But my following jobs are mostly still full-time OSS developers:
* PingCAP for TiDB and TiKV. I wrote its dev guide and built its (new) governance.
I’ve had some success funding my open source work through Patreon, I post regular updates on what I’m working on and take some feature requests from members, along with the occasional nsfw pics.
Readit News
Velocity is what you choose when you have a runway. The most successful open source projects like Emacs and GNU Make have been sitting around for about 40 years now, being slowly and steadily maintained by their owners. I've been working on a C library of my own for the past 6 years and it's only started to gain traction in recent months. If I was doing it as a startup my project would have been laid to rest in a charnel house long ago. But since it's open source, the only thing it's really cost me is time.
Deleted Comment
The workaround is to use GH Actions to auto-close PRs: https://github.com/marketplace/actions/repo-lockdown
The default reply to a feature request should be "patches are welcome". If the software is useful, people won't hesitate to contribute fixes.
In recent years I’ve noticed more than a couple projects that have been aggressive about building a community, but uninterested in accepting patches or fixing bugs themselves. It’s frustrating when the GitHub project has prominent links to join their Discord and the author is constantly pushing their project on social media, but then you open the Issues and see 2-3 year old simple issues with multiple pull requests from people desperate to fix it, but the maintainers aren’t actually interested in anything other than collecting more GitHub stars and expanding their community.
If people really want something beyond you means / energy they can submit a PR for it or fork your project.
If you're tired of replying to everyone simply have a bot close duplicate issues and let people discuss among themselves in a forum to provide peer assistance.
If its your baby and while you want to open source it you don't have any energy or desire to provide support/maintenance - just lock creating issues all together (not ideal, but if people have a community forum they'll be fine).
If you're the only person that can review/fix/maintain something then you're part of the problem, not the solution and you might need to hand over to a wider audience or flat out remove yourself as a maintainer.
"If you're the only person that can review/fix/maintain something then you're part of the problem, not the solution and you might need to hand over to a wider audience or flat out remove yourself as a maintainer."
How do those 2 parts go together?
Because the first part is correct, I don't need to do anything. But if I open source something, meaning making a gift to the world, I totally can choose to maintain with as little effort as I want to. I also don't have to provide a forum - that is a project in itself and comes with legal liabilities.
There's really no need for that. An active fork will eventually show up if people care enough. If it keeps improving, it becomes the new upstream and the original gets left behind. That's the way it should be.
Deleted Comment
That can get tiresome quite quickly. Sometimes you do submit patches but they still don't give you the time of day. Sometimes they don't actually want your code. Sometimes they only accept code from some inner circle you're not part of. You might end up wasting a lot of time only to hit these walls and end up with zero results to show for your efforts. Then one day you might discover that the maintainer committed some suspiciously similar feature to the repository all by himself.
People gotta stop acting like submitting code somehow elevates us above simple users. It really doesn't.
There is a fundamental difference between the duties of a maintainer and a developer. Just because some people are both doesn't mean they are the same thing.
Of course if your patch breaks the entirety of the testsuite (it has happened to me) and you get angry when you get asked to fix it… well not a big problem to lose such a contributor.
Deleted Comment
A) income. A chunk of mental health comes from the security of a steady income stream. To what degree does the poster have this?
B) environment? Another chunk of mental health comes from interacting with others. Ideally in person, but online is also good. Human contact, meet ups, conferences, are all good ways to feel connected and appreciated.
C) Content? Do you feel like you're doing enough? Do you feel like your projects are meaningful? Are you content with the users you have? My own mental health benefited from becoming content with my place, my work, my reach. I measure my reach in hundreds not millions, and for me that's OK.
Mental health is important, Open Source or not. But the above 3 factors seem to me to be the big hurdles for those in that space particularly.
It's ironic, but exactly the people who benefit from free software wouldn't spend their time making free software because they need money to eat.
Writing is hard. A good essay takes days if not weeks (sometimes months) of iterations. The author’s blog post is well written and a week of effort is fair, IMO.
Of course, there are some in-house tasks. But still, I spent a lot of time participating in the upstream community and became a committer after about one year's contribution.
That said, after I changed my job, my engagement decreased considerably. But my following jobs are mostly still full-time OSS developers:
* PingCAP for TiDB and TiKV. I wrote its dev guide and built its (new) governance.
* StreamNative for Apache Pulsar.
* Greptime for GreptimeDB.
Many (infra) software MUST BE open source today. You may see my explanation at https://www.tisonkun.com/blog/greptimedb-community-report#su....
1. What do you consider success? Is this less than, equal to, or greater than the amount you pay on rent/mortgage?
2. Are you building user-facing applications for a non-technical user base, or infrastructure code for a technical user base?
3. How much of your success, do you think, is based on the novelty you offer through occasional nsfw pics?
Deleted Comment