128
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 ...
45
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 ...
41
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 ...
33
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 ...
24
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 ...
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 ...
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, ...
21
I would say that projects having a BDFL ultimately trust the vision of the project to one person, as opposed to design by committee.
You can refer to the list of BDFLs.
Many of the individuals listed there have strong opinions as to what their respective project should do, not do, and how it should function (DHH and Theo are examples I am familiar with). ...
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 ...
19
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 ...
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 ...
18
I've always seen the BDFL model as halfway between a traditional open-source project structure and a traditional corporate project structure. You have the openness, transparency, and general culture of OSS, but with a single strong project manager to make high-level decisions and direct the overall effort.
You can see many of the advantages just by breaking ...
17
There are two issues here:
Managing copyright and licensing of the company's contributions in a legally rigorous way, including corporate agreement to the project's CLA, if any.
The use of a single company account to interact with the project, used by multiple employees.
Copyright ownership of the code is completely separate from the display name of the ...
16
I have started utilizing BountySource. If people are hounding you about an
issue/pull request, you can edit the issue to include code similar to this:
<bountysource-plugin>
[![Bountysource][1]][2]
[1]:https://bountysource.com/badge/issue?issue_id=4807368
[2]:https://bountysource.com/issues/4807368-support-for-package-upgrade
</bountysource-plugin&...
16
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 ...
15
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.
...
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 ...
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 ...
14
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 ...
13
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.
...
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
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,6512 gold badges14 silver badges29 bronze badges
13
The common understanding is to consider that contributions are made under the same license as the project these are contributed to (unless stated otherwise).
On GitHub, this is made explicit in the terms of service:
Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and ...
Only top voted, non community-wiki answers of a minimum length are eligible
