

An Experience in Contributing to Open Source - signa11
http://stillflowing.net/2014/12/21/an-experience-in-contributing-to-open-source/

======
STRML
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.

~~~
tnorthcutt
_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.

~~~
jghn
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

------
arafalov
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](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 :-)

~~~
ndesaulniers
I think the FCC could use your help [0].

"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...](http://www.dslreports.com/shownews/FCC-States-It-Misplaced-
Around-600000-Net-Neutrality-Comments-132102)

~~~
arafalov
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.

------
jalfresi
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".

Just makes you hungry for more!

------
bwaxxlo
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.

------
lsiebert
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.

------
swirlycheetah
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.

~~~
iurisilvio
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

* 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...](http://notenoughmemory.com/2013/01/24pullrequests-post-mortem.html)

------
gsands
Awesome dude! I've had similar experience and wish to echo this for all the
hackers with questions about how to get involved.

------
grindelwal
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.

~~~
ef4
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.

------
chris_wot
That's precisely how I stumbled into LibreOffice :-)

------
gsands
I look forward to seeing your music site on Show HN sometime!

------
maugzoide
I like de tl;dr. That is pretty much what I think.

