Interesting reflection. I agree that you can be part of the 'open source community' without committing code.
As an aside, this discourse of 'community' that has been developing over the last few years has never sat perfectly well for me. Can an activity in which tens of thousands of people worldwide participate ever really be a singular 'Community?' Communities are great in many ways, but there is a creepiness to such semantics too, such as enforced commonality of values or behavior. Can you be a skateboarder without being part of The Skateboarding Community? Maybe we need to talk about 'cultures' or 'subcultures' in tech, not just 'communities'.
I reserve the word "community" for people I physically see often, at least once a month. Virtual communities are never as grounded or fulfilling. It's a mistake to use the same word for both.
- Some hobbies use the word "scene" to refer to the 'subset of the general public that does this thing', so there's that
- A community can also refer to a diverse set of individuals who happen to have something in common. I'm a part of my local community, even though god knows there are people here who are unlike me, and/or whose values or behavior might differ from my own.
I think there is a difference in the use of the term Community depending on who is using it. To some the 'scientific community' is just a term describing the body of people writing papers, reading papers and attending conferences. To another it may mean a group of people whose collective scientific activities and values enrich that individual's life and are a significant part of their work motivation and emotional satisfaction.
I think there is a natural friction between those two views. Some people are solely motivated by their work and view other aspects of community as a bothersome necessity, or at best a source of a few collegial laughs. To others the work and the wider communal epiphenomenon are deeply intertwined: they would likely not sustain interest in the work without it.
I think both views have their merits- but they don't mix well.
People do over-apply the word a little bit. (I blame the Community Community.) The meaning has been expanded from signifying only what I would call strongly-bound communities, to include any group with something in common. People seem to want community and be eager to see it in contexts where the ties are weak.
I would say it's a bit oversold, and of course (where it exists) community has drawbacks too, such as the inevitable hierarchies, conformity and gatekeeping. And individuals usually have to give more than they get in return, to make a community work. But they are the only way to get shit done!
I checked out at "I am not yet a programmer." If the author had spent the time required to write this blog post (and all the others) learning to code...Shazam, they'd be a programmer. Maybe a few less replays of The Little Mermaid and a few books from the library on assembly language or even Basic (don't scoff, that's what I did as an 11 year old in the 80s).
Stop talking about it and start doing it. The resources to do so have never been more readily available.
Given you stopped reading at that point, you entirely missed the point of the article: that open source _is not_ just about code and yet non-code contributions are undervalued. Perhaps go back to the article and continue reading before jumping to conclusions.
I didn't stop reading, I checked out on her argument.
What the author was saying was compelling up to the point she admitted she couldn't code.
Non-code contributions have value, however if you don't have the engineering understanding to grasp the full context of a project your perspective likely isn't going to be taken seriously.
With all of the resources available now to learn to code, I just don't have any sympathy for her. At all. She doesn't need to be contributing to every project in order to have an opinion worth considering, she just needs to be able to demonstrate some level of development chops.
> I didn't stop reading, I checked out on her argument.
Then if you had spent the time required to belittle the author on lack of coding ability to address the very valid commentary provided on communal work... Shazam, you'd have gotten your point across to proaralyst. Maybe a few less condescending chidings and nostalgic recountings of 'your youth in the 80s' and a few quotations to counterargue (don't scoff, that's what many people do in discussion)?
Stop talking about 'checking out' of useful discourse and start having it. The resources to do so have never been more readily available.
Comments that lead with "I immediately stopped reading" are puzzling. If you could not sit through someone else's opinion long enough to get to their actual point, that's fine - but then you turn around and expect others to humor your recounting of that experience rather than the thread topic and read commentary that necessarily won't have anything to do with the main topic?
For that matter, why would other thread readers want to read a opinion self-declared as ignorant of the whole topic, which is likely to miss out on key points? It certainly does in this case - the author raises a valid concern within the OSS environment of the lack of incentive for 'useful nonglamorous' grunt work, yet your comment instead waxes nostalgia for your days as an 11 year old.
Discounting another's opinion simply at the point that their experiences and perspective diverges from your own (and those you consider acceptable) is practically one of the cardinal sins of open and rational thought and discussion. Frankly, I'm surprised you're flaunting it so proudly and openly.
I've only made a few contributions to various open source projects but I think that I'm an effective advocate for open source in general amongst my friends and colleagues.
One task that is often neglected, by myself as well as others, is documentation review. I'd like to suggest that anyone wanting to make contributions to open source software, and has the time and knowledge to do so, please expand and correct the documentation for any favourite projects that seem like they need it.
I have a feeling that good documentation is more important than good implementation when it comes to product adoption.
I'm going to try to follow my own advice here. There are a few projects I use that could really do with better docs, and I think that teaching people to use software correctly is easily as valid as fixing bugs or adding features.
Except that the former describes useful PRs that could be confidently contributed by someone who doesn't know the deep technicals of the item being documented, while the latter could just as easily need such knowledge.
Bad docs can be just as much an impediment to useful work as bad PRs to the project itself. Someone not confident in submitting a code PR might similarly not wish to try and 'clarify' something they don't actually understand.
Can you elaborate? I only removed the qualifier ("written by non-native / lazy / busy devs"), since almost any text that has not been copy-edited can be improved by doing just that, which requires little or no domain knowledge.
Also don't undervalue documentation feedback. Everyone makes first contact with a project only once, and the feedback of this "onboarding" can be invaluable and point to critical shortcomings of documentation.
It can be difficult for an outsider to contribute to open source projects. Very large projects don't have simple, easy-to-fix, outstanding issues. 'Outsiders' are generally not aware of smaller projects that would welcome their contributions. And these smaller projects generally have a very niche use. For this reason the majority of open source contributions I've made have been to roguelike games, and generally those that I'm extremely familiar with.
To be honest, a PR from someone who doesn't use your software, who is unfamiliar with its structure and only wants her PR merged so that she can say 'I am an open source contributor' is a hassle.
I also think it's unfortunate that the author thinks her feelings might be due to impostor syndrome, when she is quite clearly an impostor to some degree.
My best advice would be to stop looking for a repository to contribute to. Just keep using software that you find helpful, and eventually you will find yourself using a small library with some missing features that you can add. Or, just host all of the software you write on GitHub. Create nice readmes. Create issues and releases. Talk about your project in a forum of likely users. Maybe someone will contribute to your code. Boom. Now you are part of the open source community.
> To be honest, a PR from someone who doesn't use your software, who is unfamiliar with its structure and only wants her PR merged so that she can say 'I am an open source contributor' is a hassle.
This is a reason why mandatory open source contributions (yes, that's part of some curriculae nowadays) are a double-edged sword. On the one hand, some of these go on and do valuable work, others just want to invest the absolute minimum effort to pass the class.
Hah, that seems like a terrible idea. Do instructors think there is a limitless well of trivially-findable bugs that could be correctly fixed by beginning/intermediate CS students...?
I suppose if the instructor is running the project that's a different story - just upload a buggy-as-hell project with fixes you expect students to be capable of - and preclude unleashing your class on the community at large until you can (patiently and didactically, because you know them to be beginners to VCS) show them the ropes on something harmless...
Of course, I'm sure that's not the case everywhere, and god help those who have to deal with that.
Could explain a weird thing that happened to me. I used to throw everything on github as a teen, got a pull request last year to a to-do list app I'd written to learn python years ago
Have you looked at all at getting involved in the Debian project?
Previously, there was an incredible focus on developers who contributed by packaging -- to the point that voting membership required you to demonstrate your ability and involvement in packaging.
Debian realized that was excluding an entire category of contributors, many of whom were incredibly dedicated, and created an equal path to becoming a Debian developer for people who aren't engaged in packaging work at all.
We are always looking for help in countless different places; if you want to be involved, please consider reaching out to the Debian newcomers team. If a personal introduction will help you feel more comfortable, email me at <my hn username>@debian.org and I'm happy to help get you involved.
Is there a web portal out there where you can search for and connect with open source projects needing help in different areas (coding, docs, testing, design, etc.)?
Sure, the projects are all on GitHub, but how would you find projects needing help? Just go to GitHub.com, enter "help wanted" in the search field and click search?
Such portals are great for transient volunteer opportunities. But there are also open source projects with a more constant need for contributors in these different areas, and I don't think you will find them listed there. For example these are all large-ish projects that have a lot of non-code requirements and also provide support for new volunteers:
If you see something that needs a better design or documentation or whatever, make it. Put the docs up on your own site, find someone to help you do a demo-graft of your UI on to whatever it is, etc.
Worst case is $in_group doesn't use it. Docs might help someone else, your UI can be a case study in your belt. Or maybe folks want various changes, and you work through that.
Just keep in mind that functional projects and communities generally have most of the stuff essentials for immediate continuance sorted, otherwise they wouldn't exist, and they all have some surface tension, otherwise they wouldn't be distinguishable from everything else.
Also, because they're made of humans, they're rife with hierarchies, official and otherwise, and they're full of all the other bullshit people get up to. And a lot of what is bemoaned in that essay applies to any group made of talking meatbags.
I'd go a bit further... I'm a programmer, but I've done several contributions to projects where I just corrected the grammar of the README (which, I imagine, some folks would think kind of rude, but I think it helps).
Every contribution was accepted, and I think I was even thanked once!
Also, I've seen, both at my full-time day job and on open source projects that there are some people who feel that they need to be told, explicitly, what to work on, and some who just dive in and start on something.
I think that the author of this article fits, to an extent, in the first category; sometimes, those people ask for something, and are told (occasionally, alas, brusquely) "Don't bother me, get something done!"
Perhaps we need to figure out how to build a bridge to these people... without giving the impression to the "dive in" crowd that they will have to be full-time hand-holders of someone.
There are also people who are happy to self-direct but don't want to waste their time on things that will never be accepted. Some maintainers will sign off on proposals; others won't review anything that doesn't include a patch.
Every day, every month, every year we prioritize code contributions and eschew the non-code work that goes towards supporting code, we’re driving away people who believe in open source, who could be contributing.
The claim that documentation and testing are eschewed is patently false. Every software professional is well aware of their importance and when there is a related deficiency in one of their projects. Documenters, code reviewers, testers, and security folk need to know the codebase as well as anyone in order to properly document/test/review/pentest the code. While it is nice that artists, managers, organizers, and fundraisers want to get involved, they are not always relevant to smaller open source projects (which tends to be most of them).
I don't mean to minimize the experiences of the author, but perhaps she would do better to perform a security audit of her favourite project than to write a blog post about how she feels marginalized (not that the two are mutually exclusive, of course).
It sounds just as likely that you're in a bubble where it sounds like a "patently false" notion - It varies heavily by project, and as you check out smaller (and not necessarily niche, unfortunately!) teams' projects, it becomes increasingly likely that the ad-hoc'ing/prototyping patterns - that can indeed eschew 'details' such as testing/docs/maintainability in favor of 'shipping and adding features' - exist (and can even flourish, depending on the dev).
While fortunately as these projects grow the 'rest' of a process model is introduced by others in the community, it's certainly lacking enough to the degree that calling it 'patently false' would be at all accurate.
The problem of "nonglamorous/thankless work" is easily generalizable to other fields; it's not new to the field of programming. (Thus, only a fool would discount this author's thoughts on the basis of her opening with her perspective disclaimer of 'not being a programmer'.) :)
As to the problem, though - it's certainly not an easy one to solve, and not made any easier by the general need for QA/expertise to be attracted to that 'thankless job'. I personally believe that better tooling or processing is what's missing from the equation - an expert can (and does!) often try and relay elements of that pseudo-work to colleagues or themselves (in notes), but when it comes time to formalize into documentation, the 'joy' of thinking through the problem is instead replaced with the ardor of 'cleaning up and standardizing' one's thought process to meet a format.
On the other hand, process models more readily welcoming of a few 'non-code-monkey monkeys' around to handle the useful-but-overlooked work there might be an answer too.
47 comments
[ 9.6 ms ] story [ 78.4 ms ] threadAs an aside, this discourse of 'community' that has been developing over the last few years has never sat perfectly well for me. Can an activity in which tens of thousands of people worldwide participate ever really be a singular 'Community?' Communities are great in many ways, but there is a creepiness to such semantics too, such as enforced commonality of values or behavior. Can you be a skateboarder without being part of The Skateboarding Community? Maybe we need to talk about 'cultures' or 'subcultures' in tech, not just 'communities'.
The open source community exists in the same way as (and partially overlaps) the scientific community.
- A community can also refer to a diverse set of individuals who happen to have something in common. I'm a part of my local community, even though god knows there are people here who are unlike me, and/or whose values or behavior might differ from my own.
I think there is a natural friction between those two views. Some people are solely motivated by their work and view other aspects of community as a bothersome necessity, or at best a source of a few collegial laughs. To others the work and the wider communal epiphenomenon are deeply intertwined: they would likely not sustain interest in the work without it.
I think both views have their merits- but they don't mix well.
I would say it's a bit oversold, and of course (where it exists) community has drawbacks too, such as the inevitable hierarchies, conformity and gatekeeping. And individuals usually have to give more than they get in return, to make a community work. But they are the only way to get shit done!
Not enough focus on code and too many egos involved.
Stop talking about it and start doing it. The resources to do so have never been more readily available.
What the author was saying was compelling up to the point she admitted she couldn't code.
Non-code contributions have value, however if you don't have the engineering understanding to grasp the full context of a project your perspective likely isn't going to be taken seriously.
With all of the resources available now to learn to code, I just don't have any sympathy for her. At all. She doesn't need to be contributing to every project in order to have an opinion worth considering, she just needs to be able to demonstrate some level of development chops.
Then if you had spent the time required to belittle the author on lack of coding ability to address the very valid commentary provided on communal work... Shazam, you'd have gotten your point across to proaralyst. Maybe a few less condescending chidings and nostalgic recountings of 'your youth in the 80s' and a few quotations to counterargue (don't scoff, that's what many people do in discussion)?
Stop talking about 'checking out' of useful discourse and start having it. The resources to do so have never been more readily available.
:)
Comments that lead with "I immediately stopped reading" are puzzling. If you could not sit through someone else's opinion long enough to get to their actual point, that's fine - but then you turn around and expect others to humor your recounting of that experience rather than the thread topic and read commentary that necessarily won't have anything to do with the main topic?
For that matter, why would other thread readers want to read a opinion self-declared as ignorant of the whole topic, which is likely to miss out on key points? It certainly does in this case - the author raises a valid concern within the OSS environment of the lack of incentive for 'useful nonglamorous' grunt work, yet your comment instead waxes nostalgia for your days as an 11 year old.
Discounting another's opinion simply at the point that their experiences and perspective diverges from your own (and those you consider acceptable) is practically one of the cardinal sins of open and rational thought and discussion. Frankly, I'm surprised you're flaunting it so proudly and openly.
One task that is often neglected, by myself as well as others, is documentation review. I'd like to suggest that anyone wanting to make contributions to open source software, and has the time and knowledge to do so, please expand and correct the documentation for any favourite projects that seem like they need it.
I have a feeling that good documentation is more important than good implementation when it comes to product adoption.
I'm going to try to follow my own advice here. There are a few projects I use that could really do with better docs, and I think that teaching people to use software correctly is easily as valid as fixing bugs or adding features.
* documentation written by non-native speakers (and lazy/busy devs in general) needs a lot of editing and corrections.
* complete artwork (logos, inverse logos, web template, slides...)
* sorting and answering bug reports. About 70% of bugs opened on Github are just simple questions
* project management, release schedule, maintaining work queue...
ftfy:
> * documentation needs a lot of editing and corrections.
Good docs can be as much work or more as the project itself.
Bad docs can be just as much an impediment to useful work as bad PRs to the project itself. Someone not confident in submitting a code PR might similarly not wish to try and 'clarify' something they don't actually understand.
Also don't undervalue documentation feedback. Everyone makes first contact with a project only once, and the feedback of this "onboarding" can be invaluable and point to critical shortcomings of documentation.
To be honest, a PR from someone who doesn't use your software, who is unfamiliar with its structure and only wants her PR merged so that she can say 'I am an open source contributor' is a hassle.
I also think it's unfortunate that the author thinks her feelings might be due to impostor syndrome, when she is quite clearly an impostor to some degree.
My best advice would be to stop looking for a repository to contribute to. Just keep using software that you find helpful, and eventually you will find yourself using a small library with some missing features that you can add. Or, just host all of the software you write on GitHub. Create nice readmes. Create issues and releases. Talk about your project in a forum of likely users. Maybe someone will contribute to your code. Boom. Now you are part of the open source community.
This is a reason why mandatory open source contributions (yes, that's part of some curriculae nowadays) are a double-edged sword. On the one hand, some of these go on and do valuable work, others just want to invest the absolute minimum effort to pass the class.
I suppose if the instructor is running the project that's a different story - just upload a buggy-as-hell project with fixes you expect students to be capable of - and preclude unleashing your class on the community at large until you can (patiently and didactically, because you know them to be beginners to VCS) show them the ropes on something harmless...
Of course, I'm sure that's not the case everywhere, and god help those who have to deal with that.
This isn't generally true.
Large and well-established open source projects usually have dedicated schemes to match new contributors with simple tasks.
For example, here is the GNOME program which gets you started with some hand-picked, newcomer-friendly tasks:
https://wiki.gnome.org/Newcomers/SolveProject
Similarly, LibreOffice has the "Easy Hacks" project:
https://wiki.documentfoundation.org/Development/EasyHacks
Previously, there was an incredible focus on developers who contributed by packaging -- to the point that voting membership required you to demonstrate your ability and involvement in packaging.
Debian realized that was excluding an entire category of contributors, many of whom were incredibly dedicated, and created an equal path to becoming a Debian developer for people who aren't engaged in packaging work at all.
We are always looking for help in countless different places; if you want to be involved, please consider reaching out to the Debian newcomers team. If a personal introduction will help you feel more comfortable, email me at <my hn username>@debian.org and I'm happy to help get you involved.
http://up-for-grabs.net/
https://openhatch.org/
https://www.gnome.org/get-involved/
https://www.libreoffice.org/community/get-involved/
https://fedoraproject.org/wiki/Join
https://www.mozilla.org/en/contribute/
If you see something that needs a better design or documentation or whatever, make it. Put the docs up on your own site, find someone to help you do a demo-graft of your UI on to whatever it is, etc.
Worst case is $in_group doesn't use it. Docs might help someone else, your UI can be a case study in your belt. Or maybe folks want various changes, and you work through that.
Just keep in mind that functional projects and communities generally have most of the stuff essentials for immediate continuance sorted, otherwise they wouldn't exist, and they all have some surface tension, otherwise they wouldn't be distinguishable from everything else.
Also, because they're made of humans, they're rife with hierarchies, official and otherwise, and they're full of all the other bullshit people get up to. And a lot of what is bemoaned in that essay applies to any group made of talking meatbags.
I'd go a bit further... I'm a programmer, but I've done several contributions to projects where I just corrected the grammar of the README (which, I imagine, some folks would think kind of rude, but I think it helps).
Every contribution was accepted, and I think I was even thanked once!
Also, I've seen, both at my full-time day job and on open source projects that there are some people who feel that they need to be told, explicitly, what to work on, and some who just dive in and start on something.
I think that the author of this article fits, to an extent, in the first category; sometimes, those people ask for something, and are told (occasionally, alas, brusquely) "Don't bother me, get something done!"
Perhaps we need to figure out how to build a bridge to these people... without giving the impression to the "dive in" crowd that they will have to be full-time hand-holders of someone.
The claim that documentation and testing are eschewed is patently false. Every software professional is well aware of their importance and when there is a related deficiency in one of their projects. Documenters, code reviewers, testers, and security folk need to know the codebase as well as anyone in order to properly document/test/review/pentest the code. While it is nice that artists, managers, organizers, and fundraisers want to get involved, they are not always relevant to smaller open source projects (which tends to be most of them).
I don't mean to minimize the experiences of the author, but perhaps she would do better to perform a security audit of her favourite project than to write a blog post about how she feels marginalized (not that the two are mutually exclusive, of course).
While fortunately as these projects grow the 'rest' of a process model is introduced by others in the community, it's certainly lacking enough to the degree that calling it 'patently false' would be at all accurate.
As to the problem, though - it's certainly not an easy one to solve, and not made any easier by the general need for QA/expertise to be attracted to that 'thankless job'. I personally believe that better tooling or processing is what's missing from the equation - an expert can (and does!) often try and relay elements of that pseudo-work to colleagues or themselves (in notes), but when it comes time to formalize into documentation, the 'joy' of thinking through the problem is instead replaced with the ardor of 'cleaning up and standardizing' one's thought process to meet a format.
On the other hand, process models more readily welcoming of a few 'non-code-monkey monkeys' around to handle the useful-but-overlooked work there might be an answer too.