Open Source Asked by mortal36 on August 28, 2021
I’ve been foraging GitHub and making small one-off contributions to a variety of codebases that interest me. Typically, the projects that I want to contribute to are very large in nature and already have a lot of active contributors. I don’t think that adding another contributor to an already large project will do myself any good (as far as growth is concerned), nor the project (by just adding more noise).
The main difficulties I’ve found are:
Given these difficulties, what is the best way to go about being an active, influential FOSS contributor?
what is the best way to go about being an active, influential FOSS contributor?
The two goals I bolded that you seem to be asking about are quite different.
Many open source projects start because a person has a problem, and they want to share their solution with other people (the original developer is altruistic) as well as collaborate with others on solving the problem if it's non-trivial. This is often called scratching one's itch.
To take this path, contribute to a project that you personally use - identify what this project can do better that you would benefit from, implement those changes and submit them to the project. Start with a small change and if successful, move on to bigger changes. For example, almost all open source projects can benefit from documentation improvements.
The other thing that you asked about is influence. To answer this part, consider who develops open source projects:
Influence is, basically, you telling the project what it should do. Sometimes you would do part of the work (such as proposing a new feature). Sometimes you wouldn't do much work (such as asking the project to triage issues). In virtually all cases, the current maintainers have to do some work to fulfill your request. It could be a small amount like responding to your inquiry. In many cases it's a lot of work, for example ensuring that the new feature you are proposing doesn't break the software for its existing users.
Why would the project do as you want?
responses are typically "oh yeah, we'll get to that later."
There is a lack of transparency across large projects.
But you are likely mis-assessing their response with:
aren't accepting of new ideas and innovations even if they are backed up with facts and statistics
Most likely it's not that the companies think your ideas are bad, or wrong, but rather there are factors you aren't aware of (that may have been existing for a long time already) that inform the company's commitments and priorities.
Thus...
Open source is an area where everyone can contribute, but not everyone can be in charge.
As another answer notes, open source is for the most part a meritocracy, meaning those who do the work get the most say in how the work is done (but, especially in corporate-backed projects, following rules is a requirement, and sometimes there are many rules that must be followed, frequently too many for casual contributors to get through; this is why many large projects are in fact developed primarily by employees of the companies backing them). For most projects, the path to influence is through significant contributions, over a significant period of time (months, minimum). The more active and significant a project is, the more effort generally has to be expended to arrive at a position of influence. But if you think about this objectively it shouldn't be surprising.
One venue that you may consider is taking over maintainership. There are projects out there that were built by developers who no longer use them (because they changed jobs, industries, technologies they work with, etc.). Some of these projects say that they are looking for a new maintainer. Sometimes you can become a maintainer of a project that isn't looking for a maintainer but is clearly unmaintained (I personally have done this with pycurl years ago). This route can be easier than getting a voice in an active project, where you have to compete with other developers for the privilege, but still requires work because you would often need to convince whoever has the current admin password that giving you the admin access is good for the project and isn't just good for your ego. This, again, is easiest to do through contributions.
You say:
Most projects I've encountered have stale issues that just sit there without activity from years past.
These issues are waiting for someone to tackle them. When the issues are open, this means the current maintainers (people or companies) agree they should be done, but lack resources. You can take on any of these issues that appeal to you, but keep in mind what you are asking the maintainers to do with your contribution. Are you in fact following the rules, like commit messages? If not, a maintainer has to adjust your contribution prior to accepting it. Does your contribution have tests? Documentation? Etc. Think about all of the objections you have but instead of trying to get around them, find a project that agrees with how you would like to work, and try to comply with as many of these proactively as possible. Make it as easy as you can to accept your contribution. Try to make your contribution appear as if it came from the regular maintainers/developers on the project.
Lastly I would like to address this:
I don't think that adding another contributor to an already large project will do myself any good (as far as growth is concerned)
As a maintainer of a good sized project, I can tell you that in a large project there are many meaningful contributions that can be made, that are localized to a part of the whole project, and that require a lot of work. These types of contributions are definitely meaningful enough to, for example, talk about at a job interview, but they aren't anywhere close to changing direction, scope or functionality of the project overall. If you wish to build experience for the purposes of changing jobs, it can be more valuable to implement a change like this in a well-known project, especially in the field in which you seek employment, rather than be the boss of an obscure project, because this shows you are a team player as pointed out in another answer, can work well with others, understand scope and requirements, and can work in decently large codebases. These are skills that are hard to evaluate in a 30 minute interview.
Correct answer by D. SM on August 28, 2021
I'm a maintainer in various projects in GitHub with ~50 million weekly downloads but I am one person and can only share what worked for me.
The number one mistake I see people get is not set aside enough time to make a meaningful contribution, assume they're going to be awesome and then assume they failed when they don't get it right the first time.
I probably failed to contribute to projects I'm a team member of 30 times before I got to contribute.
I go over this in this talk.
Here is a very general suggestion:
I've seen this simple strategy succeed time and time again.
Making contributions to a variety of smaller projects results in knowledge ramp-up with how the maintainers want their commits and contributions done.
Don't contribute when it's hard or frustrating. Seriously, plenty of projects will work with your commits. In Node.js for example we have a very strict guideline about how commit messages look but we will format the commit ourselves for first-time contributors if they're having trouble with it.
If you feel it's frustrating there are hundreds of open source projects that would benefit from your time. This should be fun.
Most small projects typically never grow into anything beyond what it already is.
That's fine, sometimes you'll build stuff no one will use and sometimes a small package you write will get hundreds of thousands of downloads a week. It's not about getting the numbers it's about building interesting software that you find challenging, learning and helping others. I don't regret stuff I've built that isn't popular and I don't believe the stuff that is popular is somehow great.
Most projects I've encountered have stale issues that just sit there without activity from years past. Triaging is typically fruitless, since responses are typically "oh yeah, we'll get to that later."
Yes, that's true - which is why it's always better to talk to the project maintainers and acknowledging their human-ness than to try to hunt issues off GitHub. Most projects have a chat and maintainers use Facebook, Twitter, Slack or another platform with chat.
There is a lack of transparency across large projects. There's always an "in" group that's running things about how the project works and aren't accepting of new ideas and innovations even if they are backed up with facts and statistics.
That goes back to persistence. I tried getting Node to take in promises when it got a lot of resistance and I was called stupid and mocked by an "in" group many times. It's part of why I now help moderate our GitHub org.
What worked for me was persistence, making friends and understanding that it's a community.
Answered by Benjamin Gruenbaum on August 28, 2021
Many good things have been written already in previous answers. One alternative that hasn't been mentioned yet: you can always fork a project.
You are unlikely to get anywhere forking a large project and working on it on your own, but if you find a stale project where the maintainer has gone silent, forking could be a success. If you actively maintain the fork, fix bugs, add features that users want, and provide a friendly environment, users and developers will come sooner or later, and you will be not only a regular contributor, but you will have influence, because now you have become the primary developer. If I'm not mistaken, something like that happened years ago with the Python Imaging Library (PIL); the original version was never ported from Python 2 to Python 3, but eventually some people did fork the original project to make Pillow, which did work for Python 3, and now Pillow is the primary (I think only) version in actual use.
Note that with a FOSS license, you don't need to ask the owners for permission to do this: you already have this permission granted to you by the license. However, you do need permission to use the same or a similar name, as the original owner may still trademark the name. For example, if someone would want to fork Python 2.7 to create something like Python 2.8, they could do so; but they could not call it Python 2.8 without permission from the Python trademark holders (which, in this case, they will not give, see this attempt where someone tried; they wanted to call it Python 2.8, weren't allowed, now it's called tauthon instead).
Answered by gerrit on August 28, 2021
Most FLOSS projects are a kind of meritocracy: those who contribute(d) a lot, they have a say. The well-known projects are not new projects and especially the maintainers often work on them for many years.
Thus if you want to influence projects, you have to earn your standing with the existing contributors. You can only do that by friendly, on-topic discussions. And by also accepting that "this is not our way" is an acceptable answer - there are often many ways to do one thing. And there are often also many absolutely not obvious reasons to choose one or another approach, some reasoning sometimes also forgotten in history.
ad 1) If you want to work with people you will have to accept them and respect them. Everyone has his or her own way of approaching things - that includes you
ad 2) How is that a problem? Well-defined scope and keeping it that way is a good and sane thing. Not everything is supposed to become the jack-of-all-trades software.
ad 3) Those issues are often stale for a reason. Solving them might surface other problems. Or require sound and extensive re-factoring in order to not introduce too much technical debt. Or it needs to make some hard decisions no-one found the courage or the authority to make. However it can be a good idea to contact developers / maintainer and agree to go through the bug tracker and possibly start labeling issues and closing the really stale or obsolete ones.
ad 4) Sorry to say, but that sounds very arrogant of you - even when it's true. The people who run the project, do that often with dedicating loads of time to it over years. They often do that for their own fun and enjoyment in their own free time. Administration is not everybody's favourite past time - and organizing a project such that it is easily accessible can be a big task depending on how things are. They cannot pamper everybody extensively who stumbles over their projects and comes with a whole plethora of great ideas of how things are supposed to work - and who show at the same time that they are not much willing to even listening to them and their reasons why things are being done like they are. Thus:
First learn the rules. Then break the rules. Then forget the rules.
It's this order for a reason, and Rome wasn't built in a day. Each step is a lot of work which you have to do. You have to show that you are going to become a consistent contributor of quality contributions - and not a one-shot-idea guy who quits or throws a tantrum when not everything goes his way or quickly enough; take the bug tracker, submit patches for bugs. Implement wanted features and make yourself useful for the project. Those two things often go far further than submitting your own patch queue for your own new big shiny feature which just scratches your own itch. Being accepted as a core contributor is also a social decision of sorts.
Answered by planetmaker on August 28, 2021
Be more of a team player. Comments like
There's always an "in" group that's running things about how the project works and aren't accepting of new ideas and innovations even if they are backed up with facts and statistics.
would really scare me off having you as a contributor on a project I ran - even if you don't say things like that directly, it's what you're thinking and that attitude will influence your contributions to the project. There are very, very few things in software development which are so clear cut as to mean that they should be adopted on every project, even if you can find some statistics to support your position. Almost by definition, statistics are a measure for the "average" project, and there may be a very good reason why idea X isn't a good idea for any particular project.
Sorry if this isn't the answer you wanted to hear.
Answered by Philip Kendall on August 28, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP