Hacker News Reader

Comment by arcanus | Hacker News Reader

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.

View on HN

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

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

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.

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.

Awesome lists are a great place to get started:

• https://github.com/sorrycc/awesome-javascript

• https://github.com/fffaraz/awesome-cpp

• https://github.com/vinta/awesome-python

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

Reply on news.ycombinator.com