This is exactly how I felt when working with OSS. I wanted to increase my rep by contributing to OSS projects but most times I was looking for a problem that fits my solution. I was barely useful to a project as a result. Later on, I was working on a friends app (testing it) and I noticed bugs here and there. Fixed them and kept finding bugs on other projects that I was actually interested in.
That's pretty much how it happens, in my experience. Contributing to OSS projects generally happens when you need it, and often stops when you don't / it isn't your job anymore. My most significant contributions to projects always happened when I was using them in my day job. It's inevitable that a project will have bugs, or you'll want a feature it doesn't have yet.
I love it when people contribute instead of just opening issues; we're all busy, many of us maintain a dozen or more projects and it's hard to keep up when there is family, a day job, and so on. I usually merge PRs with passing tests within an hour - without tests, it could take weeks, and more open-ended "should we do X?" issues can be open for months or nearly a year.
I see this all over the OSS ecosystem in so many projects. The best way to keep a project going is to give a few people who are using it every day commit rights or encouragement to submit PRs as often as possible. If the main collaborators stop using the project, it can easily stagnate and die.
It's okay; generally, a project will eventually be picked up by someone else. All I ask of project maintainers is that they are willing to give the reins to someone else when it becomes clear that they no longer have the time for the project. Most maintainers are very good about it; some seem to have disappeared off the face of the earth. So it goes. You can always rename the project.
I love it when people contribute instead of just opening issues
I understand the sentiment, but please keep in mind that the set of people who use a piece of software and are able to file a useful issue does not always (or probably never does) overlap completely with the set of people who are able to contribute code to a project.
Well thought out issues can be valuable to an OSS project, and should IMO be thought of as a form of contributing. Same with documention.
Sure, but that doesn't mean the GP has time to deal with those properly.
I maintain a fairly small time open source package, and generally the users aren't super savvy in terms of coding, I understand that. It's an R package, and most of my questions I receive are really basic R questions, not about my software. C'est la vie.
But while I understand that doesn't mean I have time to deal with it much anymore. Responses tend to come in large batches once every couple of months just because that's when I'll finally get a chance to devote a decent block of time to the thing. OTOH if I get a non-horrible PR I handle it relatively quickly. To your point, a well thought out issue is appreciated by me, but it's just not going to get handle anywhere near as fast as a PR - that's not a judgement on the submitter, just a reality of free time
I totally agree with this. I would hate to think there are a bunch of issues with something I've made lurking out there but unreported because the people who discovered them didn't have the time or ability to fix them and felt bad about just filing an issue.
> It's okay; generally, a project will eventually be picked up by someone else. All I ask of project maintainers is that they are willing to give the reins to someone else when it becomes clear that they no longer have the time for the project
I tend to agree, but this is actually the only thing I can think of that doesn't work as well as I wish it did. Or could be improved. There's quite a lot of abandoned projects, or ones that seem active but in fact lack this steering / leadership. You can submit a PR to one of those projects and never hear back, or bump into long delays that have nothing to do with the quality of your own code or its place within the project.
In those cases, renaming the project or just forking it doesn't really create a replacement. Nobody knows which fork is the one to follow from now on. Even if lots of people +1 a PR, it's still "hanging there". And this gets exponentially more tricky with many different PRs from different contributors for the same project.
This is more a cultural than a technological issue, but worth mentioning and thinking about. I wonder if there are some tools that can help the community as a whole have a stronger force. Perhaps some voting system, or a better weighting system to point to the "strongest" fork... just a couple of very rough ideas.
I tried to participate in 24pullrequests this year but failed on the first day for exactly the reason mentioned in the article; I was forcefully searching for issues to fix in projects where I had no real knowledge of the codebase, the procedures in place or the context of issues raised.
It feels like you'd need to have a wide breadth of knowledge of multiple projects to be able to submit a worthwhile pull requests each day for 24 days.
It'd be interesting to hear from people who did complete the challenge though.
Generally my contributions to other projects have been similar to the OPs, they've come naturally as I've hit stumbling blocks in third party libraries.
I did 24pullrequests last two years. This year, I didn't actively participate (had 8 PR, but not because 24PR). It was a great experience. I tried to find new projects, related to projects I already used.
It is difficult to contribute to Django, Flask, Rails, Linux or any other large project. Look for small and undermaintained projects. They are easier to understand and have more low hanging fruits.
* I started contributing to Postmon (a brazil zip code API) during a 24pullrequests. Now, I'm a core developer of this project.
* I helped with freedomsponsors.org development a lot (the creator is a friend), looked for issues there too and fixed them (counting for 24pullrequests and receiving some money for it).
* Contributed a lot with bottlepy core, bottlepy plugins and Flask extensions
I've pretty much an identical experience; spent ages looking for open source Go projects to contribute to so I could a) improve my Go chops and b) finally contribute back after all these years. The feeling you get when your pull request is accepted with a big thumbs up is unlike anything I've had working as a developer during the day. I think it because you clearly respect the author of the project your contributing too (otherwise you wouldn't use the library in the first place!), and the acknowledgement that you are a "peer".
Reading this made me think about where the easiest place to contribute to OSS is.
Either you build code to hook up two things where there is no existing hookup (or do something someone else has done in a different language, framework, or you address a bug or add a feature to something you are familiar with. Occasionally there is low hanging fruit... like as I get better at languages, I can submit a pr for cleaner or more idiomatic code.
But honestly, If you want to make OSS better, don't code, clean, format and add to documentation/comments/examples/distribution methods. Because often useful code lacks the documentation that tells you what it does and how to use it effectively. Often it doesn't provide a simple explanation of how to install, much less a way to install directly.
The best way to get people interested in a project is to show how it can benefit them and make it easy to use.
If you are just learning, then reading and interpreting code is a skill you need to build, because much of professional software development is about reading and understanding existing code.
I think a big part of the problem of "contributing to open source" has become GitHub itself. On the one hand, it's a great product that's done tons to promote FOSS, but it's created a world where we can't "contribute to open source" without permission from a gatekeeper maintainer. It's all so centralized and bottlenecked. I understand it's matter of human nature and commercial incentives that keeps things this way, but it still seems so suboptimal as far as the software itself is concerned.
I imagine that in the future we will have a "Google for code", where algorithms dynamically find us the optimal code for doing X from around the internet without X being a single privileged master branch temple on GitHub.
>algorithms dynamically find us the optimal code for doing X
Likely will never happen.
For example:
~Counting sort is awesome with low range on inputs.
~Quicksort on user inputs is an attack vector because of O(n^2) worse case run time (CPU consumption attacks).
~Merge Sort is nice on user inputs b/c of its static runtime.
Without understanding the context of when and why sort is called, and what sort will be sorting you can't make an informed decision of what algorithm to use. A lot of this nuance escapes even very senior developers.
> it's created a world where we can't "contribute to open source" without permission from a gatekeeper maintainer.
Hasn't it always been the case that you need permission from the maintainer to get your code included in the official version? But you can still fork your own version at will, and github makes that a one-click process, which seems considerably better for distributed responsibility than the old CVS / SVN style...
> algorithms dynamically find us the optimal code for doing X from around the internet without X being a single privileged master branch temple on GitHub.
Sounds more like a publicly editable wiki for snippets than open-source project hosting
This belief that there's one blessed version of any open source project is common, but pointless.
I have contributed to dozens of other people's repos. As a rule, I make a change, share it back, but run my own fork. Later if they merge my change, great, I can point back at upstream. But it's no big deal to have your own version -- that's part of the strength of open source.
People get bent out of shape over whether upstream will merge their change, and I've heard people complain that they "wasted" their time making a change that's not accepted. But that's silly -- if you wanted the code, it wasn't a waste. Run it.
Git also makes it really easy to maintain your own changeset over time even as you incorporate upstream changes. It's pretty much designed with that use case specifically in mind.
It's wonderful when project maintainers are responsive and work to incorporate every good-faith improvement. That's the ideal. But it's also fine to fork when they simply can't or won't keep up.
On many occasions I have also merged other people's lingering/rejected pull requests into my own fork. The project maintainer doesn't have to be the final arbiter.
I decided a couple of years ago that my O/S focus would be Apache Solr. But I did not start by jumping into the source and trying to fix it. I started writing projects around it with Solr being a common-theme. And with the focus being the newbies and on-boarding experience.
And, it turned out that there is lots of opportunities. I now run a Solr resource website (http://www.solr-start.com) which is quite appreciated.
To create that website, I used Solr of course (for Javadoc search). But I also used and contributed back to Spring.io client for Solr. I cloned and improved Javadoc generator. I wrote a bunch of custom Javadoc doclets to automatically generate various lists from the Solr source code itself.
I even contributed to Python and Ruby clients for Solr by just trying to do the most basic TodoMVC equivalent in multiple client libraries. You'd be surprised how many libraries have outdated examples on their home pages due to recently changed APIs. And how many more will break when you try to do a basic example of your - rather then their - choice.
And vast majority of that code is Open Source on GitHub.
Oh, and I wrote one book on Solr and am writing another. Run a couple of workshops and presented at the Solr Revolution. And finally, I am now - slowly - starting to contribute to the Solr itself. So, it is very possible to contribute from the outside in, you don't have to start from the codebase itself.
If somebody is actually looking for O/S projects and like the idea of the Apache Solr, feel free to contact me with details on skills you already have. I have a list of at least 20 different projects around Solr which require supplementary skills I don't have time to acquire. I'd be happy to play a mentor role if it contributes to the Apache Solr ecosystem. No absolute beginners though, I am not a school :-)
You mean your users had a problem with full text search? So you solved that problem for multiple people at the expense of you having to deal with a bunch of XML files. Sounds like a win to me. After all, 2 small XML files is not THAT big a price to pay: https://github.com/arafalov/simplest-solr-config/tree/master...
"it appears that nearly 680,000 of the comments were not transferred successfully from ECFS to the XML files. This is due to a technical error involving Apache Solr, an open source tool the FCC used to produce the XML files"
Amazing. The XML files ARE the XML output directly from a Solr query (query included). And looking at it I would say they either had an issue with duplicate IDs or they did not expect any particular query to have more than 100000 results. They could have also optimized the system a bit better, as they are storing applicant and applicant_sort both, where applicant_sort could have been an index-only flag.
Yep, they could do with my help. Or with the help of solr-users mailing list which is incredible useful and has people with a lot more expertise than myself.
24 comments
[ 3.5 ms ] story [ 63.9 ms ] threadI love it when people contribute instead of just opening issues; we're all busy, many of us maintain a dozen or more projects and it's hard to keep up when there is family, a day job, and so on. I usually merge PRs with passing tests within an hour - without tests, it could take weeks, and more open-ended "should we do X?" issues can be open for months or nearly a year.
I see this all over the OSS ecosystem in so many projects. The best way to keep a project going is to give a few people who are using it every day commit rights or encouragement to submit PRs as often as possible. If the main collaborators stop using the project, it can easily stagnate and die.
It's okay; generally, a project will eventually be picked up by someone else. All I ask of project maintainers is that they are willing to give the reins to someone else when it becomes clear that they no longer have the time for the project. Most maintainers are very good about it; some seem to have disappeared off the face of the earth. So it goes. You can always rename the project.
I understand the sentiment, but please keep in mind that the set of people who use a piece of software and are able to file a useful issue does not always (or probably never does) overlap completely with the set of people who are able to contribute code to a project.
Well thought out issues can be valuable to an OSS project, and should IMO be thought of as a form of contributing. Same with documention.
I maintain a fairly small time open source package, and generally the users aren't super savvy in terms of coding, I understand that. It's an R package, and most of my questions I receive are really basic R questions, not about my software. C'est la vie.
But while I understand that doesn't mean I have time to deal with it much anymore. Responses tend to come in large batches once every couple of months just because that's when I'll finally get a chance to devote a decent block of time to the thing. OTOH if I get a non-horrible PR I handle it relatively quickly. To your point, a well thought out issue is appreciated by me, but it's just not going to get handle anywhere near as fast as a PR - that's not a judgement on the submitter, just a reality of free time
I tend to agree, but this is actually the only thing I can think of that doesn't work as well as I wish it did. Or could be improved. There's quite a lot of abandoned projects, or ones that seem active but in fact lack this steering / leadership. You can submit a PR to one of those projects and never hear back, or bump into long delays that have nothing to do with the quality of your own code or its place within the project.
In those cases, renaming the project or just forking it doesn't really create a replacement. Nobody knows which fork is the one to follow from now on. Even if lots of people +1 a PR, it's still "hanging there". And this gets exponentially more tricky with many different PRs from different contributors for the same project.
This is more a cultural than a technological issue, but worth mentioning and thinking about. I wonder if there are some tools that can help the community as a whole have a stronger force. Perhaps some voting system, or a better weighting system to point to the "strongest" fork... just a couple of very rough ideas.
* Use the fork, luke.
It feels like you'd need to have a wide breadth of knowledge of multiple projects to be able to submit a worthwhile pull requests each day for 24 days.
It'd be interesting to hear from people who did complete the challenge though.
Generally my contributions to other projects have been similar to the OPs, they've come naturally as I've hit stumbling blocks in third party libraries.
It is difficult to contribute to Django, Flask, Rails, Linux or any other large project. Look for small and undermaintained projects. They are easier to understand and have more low hanging fruits.
* I started contributing to Postmon (a brazil zip code API) during a 24pullrequests. Now, I'm a core developer of this project.
* I helped with freedomsponsors.org development a lot (the creator is a friend), looked for issues there too and fixed them (counting for 24pullrequests and receiving some money for it).
* Contributed a lot with bottlepy core, bottlepy plugins and Flask extensions
* Fixed some 24pullrequests bugs =)
* Fixed some docs
I wrote about how 24PR help people to increase OSS contribution, using 2013 stats: http://notenoughmemory.com/2013/01/24pullrequests-post-morte...
Just makes you hungry for more!
Either you build code to hook up two things where there is no existing hookup (or do something someone else has done in a different language, framework, or you address a bug or add a feature to something you are familiar with. Occasionally there is low hanging fruit... like as I get better at languages, I can submit a pr for cleaner or more idiomatic code.
But honestly, If you want to make OSS better, don't code, clean, format and add to documentation/comments/examples/distribution methods. Because often useful code lacks the documentation that tells you what it does and how to use it effectively. Often it doesn't provide a simple explanation of how to install, much less a way to install directly.
The best way to get people interested in a project is to show how it can benefit them and make it easy to use.
If you are just learning, then reading and interpreting code is a skill you need to build, because much of professional software development is about reading and understanding existing code.
I imagine that in the future we will have a "Google for code", where algorithms dynamically find us the optimal code for doing X from around the internet without X being a single privileged master branch temple on GitHub.
Likely will never happen.
For example:
~Counting sort is awesome with low range on inputs.
~Quicksort on user inputs is an attack vector because of O(n^2) worse case run time (CPU consumption attacks).
~Merge Sort is nice on user inputs b/c of its static runtime.
Without understanding the context of when and why sort is called, and what sort will be sorting you can't make an informed decision of what algorithm to use. A lot of this nuance escapes even very senior developers.
Hasn't it always been the case that you need permission from the maintainer to get your code included in the official version? But you can still fork your own version at will, and github makes that a one-click process, which seems considerably better for distributed responsibility than the old CVS / SVN style...
> algorithms dynamically find us the optimal code for doing X from around the internet without X being a single privileged master branch temple on GitHub.
Sounds more like a publicly editable wiki for snippets than open-source project hosting
I have contributed to dozens of other people's repos. As a rule, I make a change, share it back, but run my own fork. Later if they merge my change, great, I can point back at upstream. But it's no big deal to have your own version -- that's part of the strength of open source.
People get bent out of shape over whether upstream will merge their change, and I've heard people complain that they "wasted" their time making a change that's not accepted. But that's silly -- if you wanted the code, it wasn't a waste. Run it.
Git also makes it really easy to maintain your own changeset over time even as you incorporate upstream changes. It's pretty much designed with that use case specifically in mind.
It's wonderful when project maintainers are responsive and work to incorporate every good-faith improvement. That's the ideal. But it's also fine to fork when they simply can't or won't keep up.
On many occasions I have also merged other people's lingering/rejected pull requests into my own fork. The project maintainer doesn't have to be the final arbiter.
And, it turned out that there is lots of opportunities. I now run a Solr resource website (http://www.solr-start.com) which is quite appreciated.
To create that website, I used Solr of course (for Javadoc search). But I also used and contributed back to Spring.io client for Solr. I cloned and improved Javadoc generator. I wrote a bunch of custom Javadoc doclets to automatically generate various lists from the Solr source code itself.
I even contributed to Python and Ruby clients for Solr by just trying to do the most basic TodoMVC equivalent in multiple client libraries. You'd be surprised how many libraries have outdated examples on their home pages due to recently changed APIs. And how many more will break when you try to do a basic example of your - rather then their - choice.
And vast majority of that code is Open Source on GitHub.
Oh, and I wrote one book on Solr and am writing another. Run a couple of workshops and presented at the Solr Revolution. And finally, I am now - slowly - starting to contribute to the Solr itself. So, it is very possible to contribute from the outside in, you don't have to start from the codebase itself.
If somebody is actually looking for O/S projects and like the idea of the Apache Solr, feel free to contact me with details on skills you already have. I have a list of at least 20 different projects around Solr which require supplementary skills I don't have time to acquire. I'd be happy to play a mentor role if it contributes to the Apache Solr ecosystem. No absolute beginners though, I am not a school :-)
"it appears that nearly 680,000 of the comments were not transferred successfully from ECFS to the XML files. This is due to a technical error involving Apache Solr, an open source tool the FCC used to produce the XML files"
[0] http://www.dslreports.com/shownews/FCC-States-It-Misplaced-A...
Yep, they could do with my help. Or with the help of solr-users mailing list which is incredible useful and has people with a lot more expertise than myself.