An Experience in Contributing to Open Source
stillflowing.net
stillflowing.net
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 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.
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.
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.
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...
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.