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 ...
33
There are a lot of things that you can do to get other programmers contributing to your open source project.
Make the project useful for others
I think most programmers would like to contribute to and improve a project that involves something that is useful to them. It doesn't have to be something for only programmers, but if the project is something that ...
21
Note that when you say it's "unnecessary", you mean unnecessary for you. That's not the right way to collaborate: if you want others to contribute then they should have the same conveniences as you (build files in the repo for their preferred build tools).
I think you can politely reject the patch, with a remark that you would accept a patch that contained ...
17
Reject it with a message.
Don't accept it; accepting it sends the signal that this is a good contribution and you want more of them. If that's not what you want, don't accept it.
What you should do is reject it with a note explaining why, for example:
Thanks for your contribution. Your patch was rejected because it simply replaced config files. Since I ...
16
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.
...
16
Supposing your app is nice and could be some day a popular one, I recommend the followings:
Choose a nice name and description
Choose a name which has not been taken by anyone else before. The shorter it is, easier to remember. Also, it should describe somehow what your app does. Same goes for description: short, good, easy to remember and describe what ...
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&...
13
You are not supposed to trust it - Wikipedia itself tells you that it is not a reliable source.
Instead, you are supposed to trust the sources it cites in the articles. This will mostly be secondary sources, e.g. newspaper or magazine articles, books or studies about a topic, provided that these meet Wikipedia's requirements for reliable sources.
The ...
13
This works in much the same way that attracting users/a community for other things does.
You might want to look at, as suggested in the comments, Community Building, which has some advice about drawing and keeping communities.
The essential part is to be seen to be engaged: if you're not interested in your own project, why should anyone else be? Keep ...
13
In a way you are already moving forward with help from the community; that's what those pull requests are.
In addition to pull-requests, you have other tools at your fingertips
The project wiki
Which you may or may not have enabled. Like any wiki, this can double as a way for you to make announcements (publish guidelines for contributions, etc to your ...
13
Some guidelines that may be of use:
Always thank the submitter for their patch (unless you really don't want them to submit any patches anymore, which could be possible)
Establish guidelines for patches, and make sure contributors can easily find them. If you don't want IDE config changes, put it in your contributing.md (or equivalent).
Let submitters know ...
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
Open-source maintenance is often volunteer work. As a volunteer, you do not owe your time to anyone and can always say “no”. So it is absolutely legitimate to close any issue that is not comprehensible, ideally with a polite message in simple English that has a good chance of surviving machine translation. I would consider such a response to be more polite ...
11
By default under international copyright law, all copyright is owned by the person who wrote the code (or owned by the company they work for if they are an employee, or owned by the client who hired them if they are a subcontractor).
With open source projects, there can be dozens or hundreds or even thousands of people who own copyright on a project. This ...
11
I would believe that testing the project is the responsibility of all collaborators. It should fall under the hands of the contributor, as well as the maintainer. For example, a contributor should never let this go through (code in Python):
import os
os.system("rm -rf /") # Mua ha ha
Contributors should be wary of what they submit, but they make mistakes. ...
11
This is part of the purpose of version control systems, like git.
When someone makes a new feature, or changes any code at all in fact, they have to commit it to the project. It's a bit like editing here on Stack Exchange: when you edit your post, an item is created in the post's history showing the changes.
If someone sabotages your post (or in this case, ...
10
Attract a community of users
Insert some bugs
Wait for the pull requests
The above is only partly in jest - the second step will happen by accident without you planning for it.
You need to find a way to build a community and get people using the product, just as for any piece of commercial software.
Visit forums where likely users hang out, and sell it a ...
10
How about some tools that integrate with GitHub? Do you unit test your code? (Hint: You should be.) Set yourself up with a build server to automatically run the tests when a pull request is received. The tool you use will likely be dependent on the language you're writing in, but AppVeyor and TravisCI are both popular solutions that integrate extremely well ...
10
In corporate software development, all developers are, typically, using the same IDE running on the same version of the same operating system
This is a misconception. Example:
I run Eclipse Luna with openjdk-1.7 on Ubuntu 15.04, my colleague runs Eclipse Kepler with oracle jdk 1.7 (previously 1.6) on Windows.
Still we got our builds working.
The goal is to ...
10
If the project does not create and distribute a combined work of the plugin and the closed source host, then I see no realistic liability. This is because you aren't violating the GPL. A violation occurs when someone combines the GPL library with the closed source component and then distributes the result. You haven't done that, so you haven't violated ...
10
Project management, whether in closed or open development projects, is a hugely valuable role. Therefore, the way you deal with project managers is simple: value their presence, and try to keep them around as long as possible. The lack of project managers in typical open source projects doesn't mean their work is irrelevant; on the contrary, due to the ...
10
I would not expect that Rubberduck VBA, as an unincorporated organization that lacks legal personhood, is an entity that can own a copyright (though this may vary by jurisdiction). Furthermore, unless you and the other authors performed a transfer of title to Rubberduck VBA, the copyright of each contribution would remain owned by it's original author. ...
9
This is a really broad subject so I'll answer at a very high level and not touch specifics unless they are relevant for OSS.
"Works for me"
This is really the crux of the problem; you have build environments that are different in a way that affects software behaviour. The industry at large has been tackling this for decades, and a number of best practices ...
8
This situation is one major strong point in comparison to closed source software. While nobody can claim the copyright anymore and therefore the license must be kept unchanged, the software can still be maintained and developed, as this is one basic right gained through open source. It may even happen the same developers work on it.
It isn't exactly the ...
8
You should have proper comments in source code and documentation for internals. Absence of such sucks the fun out of contributing. Yes, most professional developers are fine reading other's source code. But if there is a "what's going on inside" page somewhere, contributing gets a lot easier. The topics that could be covered there are
How to setup ...
8
My recommendation is to join the development and commit-notification mailing lists for an Open Source project you have an interest in, subscribe to notifications on GitHub if applicable, join their IRC channels, if applicable. Become very familiar with using the application and offer assistance to new users attempting to use the product and/or experiencing ...
8
Every open source project has a policy to restrict who can contribute.
This is mandatory for a project to succeed in the modern era, otherwise random "contributors" would would be injecting malware and spam into every open source project.
In general, the founder of the project will only allow contributions from people they trust. For larger projects they ...
8
You need all the copyright owners' permission to change license.
There's no natural GPL-implied path here because LGPL is more permissive. It allows redistribution of unmodified binaries without the offer of source, explicitly disallowed by GPL. This makes it moderately incompatible in this direction (but you could include LGPL in a GPL work).
So in order to ...
8
I don't think you should explain the fact that you are a small dev team, working in your free time, providing zero cost software. This is irrelevant.
Emphazise that your project is an open source project. It means that it is a zero cost software once it has been paid. Currently, it has been paid by your time.
When you have a feature request, use your ...
8
Based on what I read the safety is that the process happens in the dev branch not master. Essentially no harm is done as long as someone spots the problem within a reasonable time period:
for i = 1 to 180 days # 6 months of 30 days each, this is a magic for loop that knows when a day passes
{
1. new PR gets eyeball review
2. PR is merged to ...
Only top voted, non community-wiki answers of a minimum length are eligible