Something untoward has been happening to open source, and it’s become quite apparent in recent years.
Powering everything from AI to the Cloud, open source has certainly been growing rapidly for some time now. But while all seems to be progressing well on the surface, underneath only a small number of developers are actually doing all the work.
The long-held belief was that the popularity of using open source would result or equate in an increase of those writing open source, but that has not been the case– and it’s become more evident in recent years. According to a recent survey from Stack Overflow only a mere 12.4% of respondents said they contribute to open source at least once a month or more often, and 23.1% said they contribute more than once a year but not monthly. The rest of the respondents, which constitute more than half, said they contribute less than even once a year or not at all.
Given the many benefits that contributing to open source can offer as well as how widespread the use of open source code has become, it seems odd why only a limited number of developers would contribute to it. It becomes even more perplexing when you consider that around 80% of developers surveyed said that they actually code as a hobby.
So why aren’t these developers contributing to open source projects? The answer it seems, lies with open source projects themselves.
Barriers to Entry
According to tech executive Mathew Lodge, many open source projects can be quite unwelcoming particularly to one-off contributions. A lot of work has to be put into such contributions to convince project maintainers of their value, and a lot of times contributors don’t want to or simply can’t invest their time and effort just to convince project maintainers.
On the other hand, project maintainers do have legitimate reasons to be wary of one-off contributions as many of these can take time to review, lead to complex issues or bugs, need docs, merging, etc. It’s only logical that maintainers would prefer contributions from people who are more likely to stick around– unfortunately it seems these people are becoming more rare. As the numbers have shown, only a few are consistent in their contributions.
Finding Time to Contribute
While many respondents said that they code in their free time, it appears that not everyone has that much free time, or are simply unsure that the time investment would be worth it. Most contributors after all are not paid to write open source software. Coupled with the challenge of having to prove their contributions as valuable, and the chances of contributing to open source become very slim indeed.
So what can be done? One solution seems to be a good fit for both of the above problems, and doesn’t involve project maintainers lowering their standards for contributions at all: monetization. Companies would pay their programmers to work on open source projects not just in their free time but during work hours, consequently encouraging them to be more consistent in their contributions. By paying programmers to work on open source software, companies can not only improve and steer key projects that they depend on, but also help their employees improve their skills and allow them to engage in something they’re interested in. Such a move can also foster a positive engineering culture within a company, which greatly improves company image and attracts more diverse talent.
There’s so much that open source can offer both developers and companies, but it really isn’t free as in free lunch. To obtain the maximum benefits of open source, some investments must be made, whether it be time, money or effort. Only when all those involved and who use open source software understand this can open source be benefited from optimally, and be able to flourish and grow as it should.
Why not have an annual Open Source Awards program. Award for most produced, most downloaded, best reviewed, etc.
I have contributed to open source projects since the early 1990s. My own experience has been that over the years such efforts have become less and less worth while. There have been exceptions, of course (for example, Stefan Behnel has always been appreciative of contributed bug fixes for the lxml project), but more and more often even a carefully constructed patch with accompanying unit tests will just sit and languish for years. I’m not sure how more money would solve that problem, but I’d be delighted to be proved wrong. I certainly don’t have a better solution.
I’ve retired and have more than fifty years of programming experience. My own reluctance to contribute to open source is two pronged: firstly, the learning curve for doing anything useful seems daunting and, secondly the projects I’ve looked into don’t seem very welcoming.
I would guess that the small number of people actively contributing are reluctant to divert their time to teaching a newcomer.
The result is a downward spiral leading to ever fewer active contributes.
I remember having a very similar discussion 20 years ago with a few open source advocates. It all sounded great, in theory, although I had a difficult time accepting the premises of how they saw open source evolving. What I failed to realize then was how attractive open source would appear to businesses. Not necessarily because of the quality of the software or any of the other benefits, real or imagined, but due to the single factor that couldn’t be ignored, cost. There is no argument to be made against the success of open source but the question is now, as it was 20 years ago, is whether or not it’s a sustainable model going forward.
Stack overflow may not be the best place for an open source poll…troll maybe… poll…not so much.
I would suggest an additional form of monetization. The creation of a currency for the community of developers AND users. This instrument would only be meaningful within the community (not convertible for $ or €). But it could reward developers and responsibalize the users: both can benefit from it. (not bitcoin but a well designed and managed ‘fairsourcecoin’)
I am an old school developer in C. Object orientation is a bane on our computers.
OOP eats space, devours memory and executes slowly in time critical applications, and there is little to no visibility into how this all occurs due to code bases that are strung out over multiple files, headers, IDE support scripts of various kinds, and a plethora of IDE’s that are not code level compatible nor script level compatible.
I have, on occasion, attempted to grok some bit of code that I needed further understanding, and the lack of comments, poor documentation if any, and use of some IDE that I don’t have or is not supported by the current operating system made it more effort that it was worth. I either rolled my own or simply quit the project.
The issue for new developers is much the same. If they do not have the tools, the documentation, or helpful comments, how can you expect them to contribute. I know that my experience is likely not common, but it is my experience, and likely the experience of others. Add to that the change in the desktop by Fedora, the changes to the updates and the new frequent rebooting, and you have a maelstrom of reasons not to participate.
How would you change, or what can you change to effectively speed the recruitment of new developers, and would your current developers be willing to make the changes??
Object orientation and functional programming allows far greater flexibility in a software project. Without OO or FP support, programmers have to reinvent either closures (FP) or objects (OO) with bare structs and function pointers. Countless C projects do this, the Linux kernel, the GTK framework, etc. And the C compiler is not smart enough to prevent someone to shot her own foot when working with function pointers. A OO or FP language with a good type system provides an invaluable help to ensure correctness in the code.
All of this also has drawbacks, dynamic dispatch can slightly slower than a bunch of conditional statements, automatic memory management also can hurt memory consumption and performance, but not every application domain has such strict performance requirements.
I have similar experience. I mostly program in C and Python, and I am very conservative in my use of objects, because they are expensive in memory and extremely expensive in processing time (for those who don’t know, heavy use of objects has a major impact on cache efficiency, often slowing execution speed by orders of magnitude). I program in Vim (no scripts or plugins, with autocomplete and autoindent disabled) and occasionally Notepad++, because I have not found an IDE that doesn’t significantly slow my development speed and/or constantly frustrate me by trying to help. And the last time I tried to debug someone else’s code, in a project I wasn’t intimately familiar with (which happened to be open source), I found the organization was a disaster, and after an hour just trying to find the component manifesting the fault, I gave up.
If open source developers want more help, there are some things they need to keep in mind:
I am not going to install a new IDE just so I can fix a bug or add a feature to your project.
I am not going to modify the behavior of my existing IDE/text editor for your project.
I am not going to spend hours or days figuring out your over-engineered object model just so I can help you out for free.
I am not going to contemplate every line of your code to figure out what it is all doing.
I am not going to spend hours tracking down all of your dependencies, so I can make contributions to your project.
I am never going to be interested in making major contributions, if I can’t make minor contributions.
If it is easier for me to roll my own than it is to contribute to your project, I definitely won’t be contributing.
Based on that, here is my advice to open source projects:
Avoid using IDEs that will lock in your code. I am not going to tell you what IDE to use, and if you cannot afford me the same courtesy, don’t expect my help. The same applies to scripts, plugins, and other modifications and settings for your IDE. I won’t tell you what to do, but don’t expect my help if you feel entitled to tell me what to do. (I will make an exception here for style. Style is important to readability, and it should be consistent throughout a project. I can’t expect everyone to adopt my favored style. At least choose a fairly common style though.)
Organize your project neatly. Don’t split it into multiple files just to keep the amount of code in each file small. Only split it where it is logical to do so. Big files might be intimidating, but they are better than using a separate file for each object. If a collection of things make sense as a coherent and separate group, put them in a separate file together. If they don’t, just keep them in the same file with the main code base. Poorly organized modularity is worse than using a single monolithic file. (Which is why I gave up on that debugging attempt I mentioned earlier.)
Avoid the overuse of objects. Contrary to popular opinion, structs and other composite data types are generally significantly simpler and easier to understand than objects. If I have to understand a complex object model to work on your project, I probably won’t bother. And no, you don’t need to use function pointers with your structs, unless you are doing something really strange. I know it is possible to achieve polymorphism using structs, function pointers, and type casting. (I’ve even written articles and a book chapter on how to do it.) If you feel like you need to use function pointers with your structs, 99% of the time, you are doing it wrong. That 1% of the time is where objects are actually appropriate. (Though, I’ve implemented the Observer pattern in C using function pointers without object-like structs (in a real-world application), and it was actually pretty straight forward. In my experience, function pointers are more useful for non-object stuff in C, but most of the time they should be avoided, because they cause the same cache coherency issues objects do, on top of the additional dereferencing operations.) Objects might make your code easier for you to understand. That’s because you wrote the object model. I didn’t. If it took you 40 hours to work out your object model, don’t expect it to take any less for me to understand it, and if you are not providing me with your diagram, expect it to take me several times as long to figure it out purely from your code. Object orientation is a great way for you to engineer a solution that is intuitive to you and no one else.
For gosh sake comment your code! If I have to work out what your function does by following your code, you have done something very wrong. If I have to track your code through every method of your object to understand it, I am just done. You might be able to get away with that at your job, where giving up isn’t an option for your coworkers, but if you don’t comment your open source project well, don’t expect anyone to contribute.
Minimize dependencies and find some way to make it easy for contributors to setup dependencies. If your project is only for Linux, try to stick to using libraries that can be installed using the package managers of most of the popular distributions, but don’t forget to provide a list somewhere that is easy to find. If I have to keep installing dependencies of dependencies of dependencies manually, I’m out. That might have been the only option in 2001 (when I first started using Linux), but I am not doing that ever again. Never ever include dependencies for code you can trivially write yourself. I don’t do front end web dev much, but when I do, I always write my own AJAX abstraction layer, because it literally only takes 30 minutes, even when I have to relearn how AJAX works every time. You don’t need JQuery just to make AJAX a little easier. Unless you are using a significant portion of the capabilities of the framework or library, or actually can’t reasonably do something necessary without it, code it yourself. And keep in mind, if your dependencies are all open source under a license compatible with your project’s license, you can just copy the functionality you need directly into your code, if it is trivial or if you only need one or two things. That’s better than a dependency, and it also avoids version conflicts.
Don’t marginalize me because I’ve never contributed, and don’t make it hard for me to casually contribute. If you have a policy of only accepting contributions from well known, trusted contributors, you have successfully guaranteed that your project will stagnate and probably eventually die. That’s like refusing to interact with anyone you don’t already know. How are you going to get to know new people, if you won’t interact with anyone you don’t know? I know it is easier to review contributions from people intimately familiar with your project, who you understand, trust, and are familiar with already, but if you won’t give new contributors a chance, your project will eventually run out of contributors. Find a way. Maybe see if existing contributors will share the load of reviewing contributions from new contributors. If you don’t have enough existing contributors to do this, consider putting your own contributions on hold to work with new contributors, so you can get more. I have personally submitted bug reports that I could have fixed myself but didn’t, because the project owner and other contributors just told me they didn’t have time to fix it and suggested I should do it on my own. I would even have been willing to become a more frequent contributor, because I use their project a lot, but brushing me off told me that even they don’t care much about their project, and if they don’t care, why should I? (In fact, I’ve had this experience with at least two projects.) If they had even responded with some information about the basic outline and architecture of the project, that would have given me enough information to find the buggy code and fix it myself, but if you can’t even give me that, I am not going to go searching for it myself. If you want me to contribute, get me started down the path to understanding the code base. Make it easy for me to make casual contributions, and I am more likely to keep doing it until I know the project well enough to make more valuable contributions. If existing contributors in open source projects would be more willing to mentor new and casual contributors, those projects would have a lot more serious and committed contributors.
If you can make contributing an easy and pleasant experience, I am a lot more likely to do it. Most open source projects fail badly at this. Open source projects are not my job. I don’t have anyone paying me to learn your project and contribute to it. I won’t lose my job if I just give up on contributing to your project. I deal with enough stupid restrictions, poorly organized, poorly commented code, with absurdly complex dependencies at work, and at least there, I have coworkers and supervisors willing (or required…) to help me learn the code base well enough to contribute. If I am working on your project, it is because I want it to be better and because I enjoy doing it. If you can’t make it enjoyable, I am not going to spend my leisure time working on it.
This is just how open source works. If you want contributors you can dictate IDE to and subject to all sorts of complexities and difficulties, you are going to have to pay them. That’s the only reason the proprietary software industry can produce such low quality code and subject contributors to so many unnecessary hurdles, and still survive.
Several times over the years, I have considered doing some work on open source projects. Each time I have looked at it, the barrier to entry was simply too high. A project often requires tracking down, downloading, and configuring many different libraries from different sources. I started the process once and abandoned it after having invested several hours and being only about a quarter of the way to having something I could build.
This is largely the fault of the developers. It would be relatively simple for someone to set up a repository containing a snapshot of a working setup along with a script for keeping it up to date. This just isn’t done.
I don’t have a problem volunteering my time, but I do have a problem with wasting time on grunt work that isn’t necessary.
Essa notícia me deixou bastante surpreso e um pouco preocupado, quando a RedHat passou a ser Enterprise eu deixei de usar a RedHat fiquei bastante frustrado, utilizo GNU/Linux desde o ano de 2003 e somente no ano de 2019 comecei a me dedicar na programação já pensei em entrar para o grupo de desenvolvedores mas minhas habilidades em desenvolvimento são básicas, meu sonho tem sido participar do projeto como desenvolvedor de código aberto para contribuir com a comunidade, essa notícia de Empresas pagar para os desenvolvedores foge totalmente da filosofia GNU/Linux, eu não sou contra mas também não sou a favor, não confio em Empresas e nem em Empresários e nunca vou confiar, para mim neste exato momento estamos deixando de ser livres, mas ainda somos livres, entretanto estamos correndo o risco de viver uma ilusão de liberdade de software. Preciso que me passem informações referente em como me tornar um desenvolvedor para a comunidade de código aberto mas saibam sou iniciante na programação mas estou disposto a iniciar, fico no aguardo de uma resposta de como iniciar para contribuir com a comunidade e com o tempo vou melhorando meu desempenho, dedicarei todos os dias e isso me ajudará a ser melhor na programação, preciso de alguém que me ajude a entrar para eu iniciar meus primeiros passos na comunidade, estou bastante insatisfeito com essa notícia, fico no aguardo de um retorno por email.
Most of all it seems to be the lack of reviewers which is a problem, because there is no glory and no money in it, but loads of work to be done. What could be done about that?
This is a really interesting article and agree with most of the comments – it’s about the barriers to entry. I’m a basic-to-intermediate level hobbyist programmer, and the amount of time I’d have to invest to contribute meaningfully to most open source projects is just prohibitive.
I think there is another side to this that maybe hasn’t been mentioned, which also contributes to that barrier: lack of comments. My experience is that in general, open source/hobbyist projects place a low priority on well-commented code, often because the developer was originally just one person and he (or she) didn’t need them. But that makes it even harder to understand what the code is doing, and get up to speed – especially if, as someone else noted, it’s in one of those languages that spreads itself across 50 different source and header files. You essentially have to work out the entire program logic from scratch to work it out – and ain’t nobody got time for that.
Earlier in my career, I worked for a large company that was happy to use open source, but refused to give anything back beyond a few simple code patches. This is part of the problem. Open source that is used commercially should be a two-way ecosystem.
Regarding volunteer participation, is this an area where containers could help? If a project could provide a pre-configured container with their development environment and all required dependencies in place, would that lower the barrier of entry for project volunteers?
Yes, it would. That’s almost all I’m asking. Oh, and would it kill developers to write some comments? I always extensively comment my code even when I’m the only person who is going to see it. When I come back to it after a few years, I want to be able to understand what I was thinking without deciphering the code. The concept of “self-documenting code” is something created by lazy programmers who don’t want to do the job properly.
One thing, and it’s major…
Open source programmers really need to learn how to format their code to make it even readable!
Almost every project I’ve looked at have such dismal formatting that my eyeballs start to bleed after a few minutes.
The “Univerity Axehandle” format is ill suited, to say the least, to make the code readable.
And if it’s not readable, it’s borderline impossible to contribute, and certainly not maintainable.
MEMO
AXEHANDLE
Unreadable = IReallyReallyCanNotUnderstandWhyTheOpen(source,
community,
issofondof,
the_AXEHANDLE,
style);
Three ground rules to consider:
* Always put a space after the opening parenthesis, and before the closing parenthesis, of function argument lists.
* Line-broken argument lists should *never ever* be indented to the opening parenthesis, just one indent from the previous line.
* Prototypes with anonymous argument lists should, in general, never ever be permitted.
Best Regards
/ Love
After reading everything – the topic and the comments – I am totally amazed that users enjoy so many benefits coming from the Free Software and Open Source. My sincere respect and admiration for all those who, with much or with very little, and in the midst of so many difficulties, make such “miracles” possible.