Hacker News new | past | comments | ask | show | jobs | submit login
More Common Than You Think: An In-Depth Study of Casual Contributors [pdf] (gustavopinto.org)
51 points by ghlp on June 25, 2016 | hide | past | favorite | 11 comments

Interesting study!

As a primary maintainer on some libraries and a casual contributer on others, I'm not surprised at all to see that 48% of all contributions are from the non-principle developers.

I was surprised to see that C and C++ are so low in terms of outside contributions compared to many other languages. I don't believe this is due to the number of programmers using the language, so it begs the question as to why these languages are arguably less accessible.

I don't believe C/cpp are more syntactically difficult.

If I had to hazard a guess, it would be that C/C++ code are more often specialized libraries that require system level access, and so don't attract as much of a broad interest.

Documentation. Not for users, for developers.

I cannot count the number of time I've found a bug simple enough that I know the fix is easy but got lost in the mire of a poorly-documented C/C++ (but I repeat myself...) codebase before deciding it's not worth my time.

Higher level languages are on the whole more approachable even with inadequate documentation, as if there's any other type, and even if I've never met the language before.

Your 48% is very wrong. From the abstract:

"Our results showed that although casual contributors are rather common (48.98% of the whole population of contributors in the projects analyzed), they are responsible for only 1.73% of the total number of commits."

It's worth noting that the 1.73%, are also the overlooked or edge case issues that directly effected that developers use case.

It might be a low percentage, but maybe it's the areas where portability and conformance with other libraries are important. The stuff that a core maintainer is less interested in identifying and fixing, because they are already using the library for their particular use case.

48% being the population of contributors actually seems like a fairly low number, given that your average project probably has 1, maybe 2 maintainers. If you had even 3 casual contributors to a 1-man operation, that would be 75%.

I think you hit the key word: accessibility. (IMO) If you have a tangled API, whether via the language or the library, people will be more hesitant to contribute because it cost more time and requires more complete understanding.'

I think it just rehashes the idea that OSS projects are easier to grow if they are are small and in popular languages.

Locality of changes is important too.

I've seen a project structured non-ideally for the technical task, but that enabled users to quickly find and understand the part of the project that would fix their problem.

It ended up being like the pyramids, constructed with thousands of labourers. But very successful - effective and popular.

So perhaps ideal contributor structuring is more important than ideal technical structuring...

I mentioned this elsewhere but i guess it may be worth repeating it here.

What i find most difficult about programming is not the basic syntax, but trying to get a useful overview of the libraries available.

The fact that the less powerful nature of these languages increases the amount of convention and code style required may also elevate the barrier to entry.

In a more expressive language it's easier to get to the "this is how the original developer would have written it".

Interesting paper. Casual contributor is very narrowly defined: made 1 (one) commit only. Would be interesting how some slightly less limited definition would change results, or not.

The analysis also excludes all contributions not in the form of commits. Of course including non-commit contributions is hard.

One minor nit: C is characterized as "strongly typed".

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact