125
There are lots of things to do around open source projects which do not require any programming knowledge at all. Among them are things like:
User Documentation: Programmers love writing code but hate writing documentation. And if we like to write documentation it's mostly the technical documentation for other developers. As a result, many open source ...
50
Define objective criteria that any contribution must fulfill. Automate checks for these criteria, using unit tests, linters, code coverage tools, …, then automatically run these checks for each PR as part of the build process / unit tests. Fortunately, there's a large set of such services that are available at no cost for open source projects.
If a ...
47
Put it on the front page.
Put it in a pinned message at the top of the forum.
Stop worrying about it.
Find a way to create a marketplace where people can put up money if they care to, and someone else cares to take it.
You don't owe the universe anything. You and your colleagues built what you built to scratch your own itches and made a gift of code. If ...
44
Testing.
You don't have to be a programmer to test a program. Use the program as it's designed to be used, but also use the program at the extremes or with "corner cases" to try to break it. In either case keep detailed notes as you work so when it breaks or misbehaves you know how you got there and can make it happen again. Conscientious ...
38
As far as I am aware, all FLOSS licenses that deal with copyright notices only require the preservation of notices that exist. Each author had the opportunity to add their own name to header when they made their contribution. If they chose not to do so, there is no existing notice from that author to preserve. There is never (as far as I know) any ...
24
Make it clear that you want contributions.
Make it easy.
I would start by putting a friendly note in your project's ReadMe file.
This project is looking for contributors. If you have a feature you'd like to see implemented or a bug you'd liked fixed, the best and fastest way to make that happen is to implement it and submit it back upstream for ...
23
You, as the maintainer, can decide what you merge into your project. That doesn't prevent others from forking and maintaining their own version of the code though.
If you post the code to some place like GitHub or other code sharing service, you are given a set of permissions that determines who can merge changes to your master branch. It is not something ...
22
You might want to check out e.g. Fedora's page on how and for what to join. You'll see plenty of tasks for non-programmers. Some of the highly regarded members of the Fedora community don't do any programming.
Fedora looks for people interested in content writing (tutorials, write articles for their magazine, documentation in general), design (artwork, ...
20
Where can I start contributing?
There are two obvious stages to this: pick a language, pick a project.
Pick a language
You should pick a language with which you are familiar and proficient. I'd advise not trying to contribute to projects in languages you're not that great in - yes, it is a good opportunity to improve your skills in that language, but it's ...
19
One-off contributions are the most common type of contribution in open source projects. It would be very disturbing to know that, by running an open source project, I'm spreading guilt throughout the world! Fortunately that's far from the truth.
From experience, one-off contributions are almost always useful, even if about half the time the contributions ...
18
Don't merge, unless it meets your demands. All contributions are welcome, but only those that meet your standards are merged.
Whether that is test coverage, a style guide, or documentation, it shouldn't be merged until it's OK. You can choose to do it yourself when you're merging, or you can turn down the patch until it does.
As the maintainer, you are ...
15
Linus Torvalds has talked about his experience on this subject; the book Producing Open Source Software also has a section that deals with difficult people, which is mostly related. If you want to read more, look these up.
Maintain control. How is it possible that contributors can do damage in the first place? Did you give them commit privileges without ...
15
Advantages
Reduced maintenance. If a company uses custom patches, every time upstream changes, the company has to re-apply those patches when they update their custom version. This gets worse when upstream undergoes major refactors or changes in interfaces.
Publicity. By having its name included in the project's contributor list, other users become aware of ...
15
To me, this question is very similar to how do I attract customers to my business? except instead of cash, you want contributions. Successful salespeople deeply understand their customers' needs and tailor their services to address those needs. It's a very powerful method: put yourself in your potential contributors' shoes, and ask what's stopping you. Many ...
15
This is a legitimate issue that's come up various times in the past on various open source projects. The way it's typically handled is by not accepting external contributions into your repository unless they sign an agreement either transferring their copyright interest to you or, at the very least, explicitly waiving their right to disagree with your ...
14
I think you're mixing up two concepts here. The quote you provided is for people using your software. If you want your software to be open source, you have to accept that everyone is permitted to use it.
Accepting contributions is a completely different cup of tea. As a maintainer you can accept or reject whichever patch you like. Look how Linus does that ...
13
One of the greatest assets are people experienced in web design/development.
I find that this can be incredibly underestimated: websites are the platform for many projects to advertise. But they are also relatively underused. While some projects such as Github Pages make the job easier, it can be very hard to have a site that is both unique and attractive, ...
13
There's one thing that I hadn't seen proposed yet: ideas. You might actually have some good ideas that can be discussed on the project's mailing list and end up getting implemented - the more thought over, the better. By not being a developer you're more likely to be the "regular user" kind of man and you can use it to your advantage by proposing things that ...
13
Should I list myself as author, and original author as contributor? Or should I somehow refer to the company in general? Or it is legal to only mention myself here (and leave the reference to company in README, which I feel I must do anyway)?
The documentation for the package.json file says that
The “author” is one person. “contributors” is an array ...
12
Simple answer: nope. I know this because I've made open source software and I don't have a degree.
The degree isn't required because the knowledge of programming required to make software doesn't change between proprietary and open source software. You still need to able to write good working code, and that doesn't require a degree - you can teach yourself.
...
12
This is where the problem (or advantage) of multiple copyright owners comes in with open projects. There are two scenarios, based on whether a Copyright Transfer Agreement (CTA) is required to contribute to the project.
If a CTA is required to make contributions, then the issue is moot as the organization running the project becomes the copyright holder.
...
12
Been there, done that.
Why does it happen?
In my experience, a split due to creative differences usually happens because different people have a different idea of what the project goal actually is, but nobody is aware of that. As soon as a contributor realizes that someone else's vision is different from theirs, arguments and power struggle will start, ...
12
How and where should a newbie like me start?
Pick a project you use, and that you think can be improved (a bug needs fixing, there is a feature that you would like to see added). Make sure your contribution is small and focused.
How does the contribution flow works in open source projects? (Like first maybe you monitor activities in that open ...
12
The world of open source is, almost by definition, one in which groups of complete strangers come together to combine their talents and produce a unified result. There may well be some projects where all contributors know each other and have great experience, but in the main you will be judged on the quality of your contributions.
So, I think it is fair to ...
12
Since the Phoenicians invented money, one of the possible answers is clear. Many open source projects has a possibility to donate.
11
We have run into this problem in libpng. We addressed it by putting any contributions that insist on keeping their own copyright, or are under a different open source license, into a "contrib" directory, which has its own README.txt:
This "contrib" directory contains contributions which are not
necessarily under the libpng license, although all are ...
answered Oct 10 '16 at 15:14
Glenn Randers-Pehrson
3,5112 gold badges11 silver badges27 bronze badges
10
In general, if you write the code, you own the copyright.
You may have written module A, or the file B, or the function C, or the line D. Doesn't matter who else worked on those parts, the parts you write are your own, and the parts you didn't write aren't.
The only difference is that, since this is an open source project, your co-contributors have the ...
10
The primary way to contribute is by pull requests, just like you said. If your pull requests aren't accepted and you do not get any comments the project might as well be abandoned.
In this case I would open an issue/ticket and ask if you can participate as an maintainer. If you do not get a reply, create your own fork. Write a comment in your issue and say ...
Only top voted, non community-wiki answers of a minimum length are eligible
