I think one issue that the paper didn't really tackle was the question new contributors ask themselves when they want to contribute: "I don't want to bother people with patches they could have written themselves faster or better." (http://marti.us/w/2014-07-19-Mozilla-BSP.html)
When I first started out, I reported bugs, reproducible tests, and contributed to issue discussions, but didn't write PRs because I felt as if my coding style or complexity could not live up to the source. There is often a intimidation factor when thinking about submitting code to the maintainers (even though it is not on purpose).
Even now after contributing some code, I sometimes still feel the same way when it comes to repos by well-known names in the communities.
This is great. I want this information to be in a form easily accessible and readable for any project maintainer who wants to learn about concrete ways to improve their projects. So, question: what form should that be? A blog post explaining the highlights, with a title with good keywords? A YouTube video with explanations and anecdotes, like a talk without a conference? Where do maintainers learn about this kind of thing (other than occasional news posts on HN with advice), so that we can make this information show up there?
I volunteer for OpenHatch (https://openhatch.org/), a non-profit open source project that aims to help newcomers contribute to projects + help projects make themselves more welcoming. What do you think is the most effective step OpenHatch could take for helping maintainers? It has some efforts already, and I have some ideas, but I'm curious to hear more ideas. (Also if you want to help, OpenHatch is already a loose collection of people who care about this; come join us.)
I would personally go with a "Best Practices" page that streamlines the info. I have a very long history of doing volunteer work of various sorts. Some of the early observations are things I am familiar with but I find this paper rather clunky.
I suspect there are no easy answers for some of the barriers they list. (For example, I feel like "lacks the skill to do the job" is probably not something the project manager can or should solve, anymore than a hiring manager should take just anyone who wants the job even though they aren't qualified.) But the social piece is something I can break down for you into basically two key points:
1) Greet people warmly at the door.
People who get that initial "Hi! How are you? We are so happy you dropped by!" kind of response are much, much more likely to keep coming back, even if it takes a bit to figure out where they fit in. Folks who get the cold shoulder often just disappear, never to be heard from again.
2) Never let any question go completely unanswered.
If it does not get a meaningful answer in a timely fashion, then the person in charge should at least drop the person a note to say "I don't know the answer." (When I had a directorship on a voluntary health and welfare organization trying to make the transition to full scale charity, my rule of thumb was that if it had no response after 3 days, I would step in and say something, even if I had no answer.) Depending upon the environment in question, that sometimes bumps the question and allows others to notice who may have missed it due to being away, busy, whatever. So, sometimes just answering nominally will get it answered meaningfully by another but even if it doesn't, the person doesn't wind up feeling like they are out in social Siberia and afraid to speak up again.
Open source project maintainers might also consider a lighter-weight implementation, a CONTRIBUTING file, per Brad Fitzpatrick's CONTRIBUTING project: http://contributing.appspot.com
I dunno; having project members not actively be dicks to newcomers is always good advice.
That said -- and I'm being vague because some people on hn are dicks and I'm careful how trackable my online presence is -- small projects get lots of, well, basically useless people who need tons of handholding to get anything accomplished. I see the upside for them, but I don't see the upside for me: if I where to help them out, I'd spend my limited available time on handholding people who apparently managed to get ms degrees in cs without being able to code instead of doing what I enjoy. So I ignore them. Open source is apparently the new resume chit so people want to spend minimal effort to put a patch into a github project. We're always open to helpful people but I have a depth 1 decision tree for ignoring the idiots: if you can't successfully read and follow the instructions in readme.md and make, you're worthless and I kill your email.
This is a bizarre statement. There are plenty of reasons to write software that don't revolve around "I want this software for my own personal benefit". For example the person in question may just want experience of programming, and/or they may wish to contribute to something that helps others rather than themselves.
(I suspect many people are in a similar position in their day job, given the existence of large amounts of software for which the target audience is not computer programmers.)
I wasn't really trying to distinguishing between personal quantifiable gains from other gains. My being annoyed for someone else whose showed me ridiculous workarounds is a perfect example of a reason I would fix software so >I< can feel better about reality, myself and experience less pain and embarrassment for my profession if I help them again in the future.
For pure experience programming, sure we write "garbage software" to make the changes in ourselves. But if it is worth sharing (even for edification or statistical analysis) then we go back to a personal reason otherwise it has little relevance to the larger topic of discussion, and I personally focus on the garbage in "garbage software" rather than software.
The one that does not have dozens of ignored three years old pull requests and decent level communication with newcomers on mailing list and in issues.
False alarm! This paper is not about barriers in actually working with open source, but largely about what I would call "barriers a newcomer faces in their quest to be accepted as an esteemed contributor or maintainer, with their name stamped the project, and their changes in the official trunk 'n everything!".
If an OSS program is not doing something that you would like, you can get the code and fix it. No waiting for anyone's response, no mentorship, no B.S. Moreover, you can publish your patch somewhere without upstreaming it to the original project.
I have recently done this with three programs: rsyslog, the Lurker mailing list archiver, and a MIDI sequencer for Windows called Sekaiju. I made these programs do what I want, and put my changes in public git repos hosted on my server.
Speaking of Lurker: I developed a way to show HTML mailing list posts as actual HTML in the web archive. The Lurker maintainer was vehemently against this on security grounds (even though I implemented a HTML filter which validates for a set of allowed tags and attributes.) The feature needs more work: namely, image links do not work properly. You can see images as attachments (existing feature), but the links within the HTML to the images are broken: they are the original URL's which need to be re-written to point to the archiver-generated URL's. This could be done in the "HTML cleaner", which is an external program hosted here, not originating from Lurker:
This reads like an academic version of my essay, "How to get designers (or anyone) to work on your open source project," which is pretty exciting.
If you're a project leader that wants new people, whether devs or designers or doc writers or anyone, http://opensourcedesign.is/blogging_about/import-designers/ is my essay, and it provides concrete steps you can take, with real examples from a technologically non-trivial open source project.
It looks like my essay hits all the points from this paper, which is nice to see.
Many open source projects use IRC as a main communication channel. I've heard that newcomers find IRC hard - they are used to Skype, Hangouts, chat apps, etc. How is this barrier overcome?
The simplest approach I've seen to address this is to embed an IRC chat widget on the project website. Now there's no software to install or configure in order to chat with project members.
This doesn't address some of the cultural expectations in IRC (don't ask to ask, use something like pastebin, stick around because it may take several hours for someone to answer you) but it at least gets over the initial hurdle.
A lot of the chat apps have IRC support. I was part of a channel where the majority of people were using Adium (Mac) or Trillian (Windows). It was pretty easy to get people to join if they were already using one of these IM clients for AIM/MSN/etc. For people who don't already use a multiprotocol IM client like that, I often point them to Mibbit as a quick web-based way of getting on: http://mibbit.com/. But the people already using an IM client were more likely to become regulars.
I'm a maintainer of a reasonably big open source project and it works great for us, since you can link issues/PRs directly and get a Github activity log right next to the chat.
It also preserves the chat history, which was one of the big reasons to switch over from IRC.
Abstract over the outdated IRC cruft, but use IRC as the communication medium. Some ideas:
- Process all user-input so that they can't run commands or do other crazyness in the channel.
- All commands and actions other than chatting are to be handled by the client. This also allows for "IRC2" type commands that aren't part of the IRC spec to be handled "in-band" in the channel, but not seen by any users.
- Channels have a built in admin bot that handles client commands, sets restrictions on channel content, manages mods, channel ownership, names etc. This should be invisible to most users.
- The client should enable end-to-end encryption. Maybe public-key so that user identities can also be verified.
- a user using a normal IRC client and logging into one of these "IRC2" channels would basically just see a bunch of users communicating in encrypted gibberish and not be able to participate
- the client should let people post and view links to images, videos, etc. and automatically embed them in the chat client. Embedded media should stay collapsed until the user clicks it, but then they'll see a resized image or an embedded youtube video, or a player around a soundcloud song or whatever.
- people should be able to nominate awesome quotes to "archive" into a subset of the logged channel.
- channels should be listed on an entry page. Let's get rid of stupid sigils like # and other nonsense. Just show the channel name.
- people can establish private group channels (like a hangout) or 1-1 channels, access is controlled by the default channel bot.
- video or voice chat would be handled outside of the IRC server, but setting up the communications could be handled in-band.
Feel free to knock any of these down as bad ideas.
That's the problem. Most of the IRC clients I'm aware try to bury as much IRC stuff as possible in the GUI rather than simplifying and abstracting the experience away. I think there's probably a big opening here.
the ability to download a client that is widely available for all platforms and follow simple instructions to join a channel is a useful filter at least for potential code contributions
It is if you create an academia.edu account, but not otherwise.
This is a direct link hosted by the first author, from his publication page [1]: http://www.igor.pro.br/publica/papers/OSS2014.pdf. It's on a university server and publicly posted, so I think should be ok to link to instead of the academia.edu link.
When I first started out, I reported bugs, reproducible tests, and contributed to issue discussions, but didn't write PRs because I felt as if my coding style or complexity could not live up to the source. There is often a intimidation factor when thinking about submitting code to the maintainers (even though it is not on purpose).
Even now after contributing some code, I sometimes still feel the same way when it comes to repos by well-known names in the communities.