Contributing to open source can be one of the best ways to start or advance your career. But there are often barriers to getting started in Open Source. What are some of the reasons that prevented you from getting started in OSS?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (41)
I've been an OSS contributor for the better part of a decade now, my biggest contribution being to the Apache Cordova project, but these days I run a few little niche packages that require low maintenance. I even wrote an article that got a bit of buzz last fall about How I Maintain OSS Projects.
One common misconception I frequently see with this question is what actually counts as a contribution. Many do not realize that you don't actually have to write code to contribute. Submitting bugs and participating in open discussions with the maintainers also count as contributions. Github's contribution graph actually reflects this today.
As far as "What's stopping you from writing OSS Code?", my observations after working with several hundred engineers over the years:
I also believe that community participation -- e.g. answering questions on a forum/Discord/Slack/whatever -- is a significant contribution.
And if I find a bug or unclear documentation in a FOSS language or library we're using at work, you better believe I'll open an issue or a PR on company time. Supporting projects that we depend on is a no-brainer.
Community participation is huge, esp when a project wants continued contributions.
This comment seems to assume that "contribution" means creating your own project. I think we should put a lot more emphasis on contribution to an existing project run by some other person. That would take out the "Burden" and the "Uninspired" and even the "Non-package Mindset" from the above list.
Personally I also feel that the "People know what they're worth" is outrageous. (to not use any stronger word.) It is people who think they can use the work of others without giving any value back.
That still leaves us with lack of ambition and the lack of capacity, that is, not everyone is in the situation that can allocate time for stuff that does not pay.
We can agree to disagree as to what points are valid in what contexts, but the comment itself was written from both. Burden and Inspiration are very much factors with potential participants doing non-coding activities like bug reports, feature requests, and discussions.
Yea this is on point, my answer is a version of most of the points listed above. Like 4 of the 6 ring 100% true for me.
Well played.
Thanks for sharing, Joe. These points are super important in the conversation, especially when companies depend on using OSS packages.
Aside from what others said, to avoid repeating sentences, bad or inexistent technical documentation is a red flag.
On the other side, during those last years tones of "Open Source" softwares have been released with a funded company that owns the repo and makes money with the software itself (usually SaaS) and the business model is planned waaay before a single LoC is provided, the business structure is set (and consuming money) weeks before they create the public repo. A private repo with the App to monetize the future OSS since the day one is up and running before anouncing any OSS thingy.
In other words and to clarify, they seek for free workforce just by adding the "OSS" badge and just for the piece they will benefit by reducing costs in development and maintenance, the thing that requires more effort: the product.
In this scenario I'd rather waste 20 hours developing a non-viable thingy that will end up in the trash just for fun, or picking a side-project that actually increases my income than spending 5min working for the profit of a third party, be it "OSS" or not.
The process of contributing to OSS can be time-consuming, which is a luxury that many developers do not have.
Developers are typically very passionate about their work and want to be associated with high-quality software that solves real problems. Contributing to a low-quality project may not align with their professional goals, and may not provide the satisfaction that comes with building something of value.
But some developers may also be concerned about the quality of their contributions, and worry that they will not meet the high standards set by the project. This fear of rejection can be demotivating and can lead to a reluctance to contribute further.
Depending on the project, this can be very justified. It takes a maintainer maybe 5 minutes to write a constructive comment "please refactor X into a class, and remember to run Y for linting before pushing", but some people can't even be bothered with that much.
But in my experience, the worst case is when both things happen at once: The higher level design of a project is really painful to work with and extend because the necessary changes fall outside of some unfounded assumptions, but the quality of the code on a line-by-line level is controlled pedantically.
That sort of thing just takes the joy out of participating.
Fear of rejection is a big one.
Truly is.
I do occasionally actually. I make changes that I need in open source projects, and create my own libraries and tools when I feel inspired. What holds me back from doing it more though are two things:
The hoops you sometimes need to jump through. For example, projects have contributing agreements (like ReactJS) or require extensive tests to be written for small changes. This discourages me from making a small change, because of the extra work beyond the fix or feature.
Lack of engagement. When creating my own tools and libraries, I've never received much traction from the community on them. Is this expected? For sure! NPM for example has somewhere around 1.3 million packages, most of which live in anonymity. It's never the less discouraging to put hard work into something only to have it never catch on.
All in all though I always get a great deal of satisfaction from a successful contribution. And if I build something of note that would be great too!
That makes a lot of sense, Ryan. Thanks for sharing.
Do you have any thoughts on how to fix these issues? I have some thoughts, but I'd love to hear your ideas.
I don't have many thoughts actually, I can't say Ive seen these issues as anything but inherent to the work and projects.
I suppose collaboration around issues for the first. Maybe more active assistance from maintainers to ease the pain of requirements. As to the second, if I knew it wouldn't be much of a problem! ☺️ Maybe more active evangelism and relations work than I've done in the past?
I do, actually, but not on a regular basis - rather in a "reactive" mode, when I encounter a bug in a library I use. I believe this is most common root for open source contributions.
But this aside, I never really participated in the development of a open source project. I'm talking here about doing regular contributions, knowing the code inside-out like I do with most of the code in my work. The reason for this is that it is actually very hard thing to do (at least for me). Many projects have their "committees" that make decisions and contribute often and, even if it's not intended (and I believe it usually is not) they seem quite reluctant to "let somebody else in".
Also, unfortunately, due to multiple low-quality contributions and demanding, entitled users maintainers sometimes wave you off if you are not a part of a known circle. I absolutely don't blame them for that, being a maintainer must be super hard, but it's also often a reality that I - an occasional contributor - experience.
Thanks for this answer. It sounds like creating a welcoming space and having good onboarding could decrease some of these barriers.
I've been saying it for years now, but medium-sized open source projects could really use non-developers on board - technical writers, community managers, maybe even project managers, people that mostly just triage issues... Let the developers do what they are good at.
But the big question remains - how to attract such people to open source, which has traditionally been just developers' ground.
I think last year's Hacktoberfest did a much better job of doing that. But you're 100% right, that OSS needs more non-devs.
One of the biggest barriers for me was imposter syndrome. I was worried about the quality of what I could produce, and I was concerned that I would look stupid if I didn't know what I was doing. I think a lot of newer devs share this mindset.
Also, open source projects were either too small or niche to interest me, or so huge and advanced that I didn't even know where to begin. It was extremely difficult to find the middle ground I was looking for, in a project that was also tolerant of newer devs.
What I really wanted was a community that had projects going that I could grasp, had a team that wanted to lead newer devs in getting comfortable working in a group, felt safe for inexperienced people to make mistakes and learn, and focused on the people involved as a priority over the final product. Kind of a bridge between tutorial hell and being ready to venture into the greater dev world.
I never did find that community. So I'm building it ;)
That sounds awesome! At Virtual Coffee, we do a big open source month in October where we pair with contributors and support maintainers. I’d love to know more about your community.
It's in a planning stage and I've been making some decisions on how best to proceed and reaching out to a few people for insight. There's a good chance it will be an extension of another rather well know community based on some discussions I've had, which I wasn't expecting but is possibly a huge leg up. I can start putting the time into infrastructure starting about May 1, and so far I have a handful of people interested in the leadership / mentorship side as well. Once things start building I'll start making some noise around the internet to get people involved.
I've never really gotten into open source. If I'm really honest, it's probably because I enjoy starting new things more than working on existing things, and I like to show off random things that I 'invented'. Also, since I never got started, there is probably some factor of momentum involved that would kick in if I just gave it a try.
I'd like to say that the real reasons are that I only have so much time, family comes first, and there are better things to do with my time. While these are certainly factors, they are probably not the primary reasons.
I also have certain opinions about open source, mostly already articulated. The fact that open source lets people see what the software is actually doing (and not other stuff), and opens the opportunity to provide feedback is great. But there clearly is an issue with funding and the expectation that good products must be made by a community of unpaid developers on their own time.
That being said, after talking to Nick Taylor and others, a large percentage of successful developers working at top companies got there because they stood out as open source contributors. Maybe this shouldn't be the case (as brought up by Chris Krycho in his New Rustacean Podcast Bonus Episode 5), but it is the reality we live in, especially in the current job market. Recently, I have been looking for ways to make myself stand out as a candidate, and that probably will involve diving into open source contributions.
Open Source contributions is one of the most public ways you can demonstrate your communication skills, coding abilities, and ability to navigate a large codebase.
That said, would you ever flip it: you create and maintain a project, and work with contributors? I’ve really enjoyed that experience.
Perhaps! I do have a few projects I created that are open source, but they aren't huge. I just need to find something that I really enjoy and dive in.
I have contributed to several open-source projects. However, I would like to say that they were relatively small projects and not well-documented. When I attempted to contribute to larger projects such as the React library, it was very challenging.
To contribute to such projects, we need to understand clean codes, unit tests, and the contribution flow, which may not be suitable for mediocre programmers. These challenges and barriers could prevent us from contributing.
But, I have found an easier way to contribute, which is by translating documentation into different languages. Although it may involve a lot of tasks initially, it is relatively easier to carry.
My job dosen't really have built-in time to contribute. Outside of work I have too many personal projects/other things going on to contribute.
Totally get that.
I have occasionally contributed smaller things to projects, but for the most part, I just prefer to write my own stuff from scratch. It may not be as useful to other people unless any of my little projects miraculously takes off (which I doubt, given how they're often purpose-built for my way of doing things), but it's just way more enjoyable than spending time experimenting with, implementing and polishing a feature only to be told that's not really the direction the project is being taken.
And on top of that so many open source projects are just so needlessly over-engineered that any meaningful change requires a lot of up-front work in getting to know the system.