Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Experience in Contributing to Open Source

stillflowing.net

Post reply on HN
Print view View original

11–20 of 25 posts

Re: An Experience in Contributing to Open Source

#11

Post by 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.

Re: An Experience in Contributing to Open Source

#12

Post by valarauca1 »

grindelwal wrote: post #11

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, b…

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

Re: An Experience in Contributing to Open Source

#13

Post by Shish2k »

grindelwal wrote: post #11

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, b…

> 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

Re: An Experience in Contributing to Open Source

#14

Post by iurisilvio »

swirlycheetah wrote: post #7

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 e…

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

Re: An Experience in Contributing to Open Source

#16

Post by ef4 »

grindelwal wrote: post #11

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, b…

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.

Re: An Experience in Contributing to Open Source

#17

Post by 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) 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 :-)

Re: An Experience in Contributing to Open Source

#18

Post by tnorthcutt »

STRML wrote: post #6

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 o…

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.

Re: An Experience in Contributing to Open Source

#19

Post by gingerlime »

STRML wrote: post #6

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 o…

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

* Use the fork, luke.

Re: An Experience in Contributing to Open Source

#20

Post by jghn »

tnorthcutt wrote: post #18
STRML wrote: post #6

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 o…

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…

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

Post reply on HN