42

Just to play devil's advocate: One thing you may want to consider is that your current documentation might be suboptimal - no one may be reading your documentation because it isn't useful (to them). How easy is it to find your documentation in the first place? How easy is it to find a given topic within your documentation? Is there a clear path for a ...


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 ...


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

There are a bunch of strategies that help you deal with beginner questions. Not all of them teach to RTFM, but you don't have to. Some strategies that can be very effective: Mobilize your userbase for support. Have a proper real-time communication platform (IRC, commonly on Freenode, and/or Gitter) to ask questions, as well as a mailing list. Users can help ...


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

You're conflating features of the Stack Exchange engine, which copyright law doesn't care about, with ownership and licensing. All user content (i.e. the posts and comments, not the user interface bits) on Stack Exchange is owned by their authors (there is no transfer of copyright — that's not even a thing in some jurisdictions; it is in the US but SE doesn'...


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

Ultimately, if the developers are working on the project as a labor of love, they're going to work on what they want to work on. You can't expect them to prioritize your issue just because you asked them to. Instead, you can try to add incentives to make it more likely that your issue is one that they do want to work on. I can think of a few options, ...


11

What you're describing is called a Version Control System or revision control system. It essentially stores one canonical copy in a central place, which can be downloaded, edited, and committed back there. If someone else changes it in the time you do, you must review those changes and incorporate them into your code before recommitting. Some major version ...


10

(disclosure: I am a supporter and my company is a silver member of the Linux Foundation). TL;DR: Higher levels of membership pay bigger fees and have more say in the running of the Foundation with Board of Directors seats. Yearly fee for Platinum is $500K+, Gold is $100K, Silver is $5K to $20K. Individual supporters pay $99 and Student get in for free. ...


9

Significantly less female participation. It is estimated that female participation on open source projects is at about 2%, compared to 10-30% overall in computing or proprietary projects. For overall female participation, NSF keeps employment statistics for women, which has hovered around 20-30% for the "computer and math scientists" category. There are a ...


9

"Nobody" reads the f-ing manual. But let me detail my answer a bit. It's statistics you see... One only reads the manual when there is absolutely, positively nobody around that even remotely has knowledge on the subject matter. Anything, everything is better than the manual, because the manual doesn't contain THE answer to your question, it also contains ...


9

Apsillers' answer is perfect, I will just add a case study about the last paragraph ("Money talks"). My open source project (1.5 million users) has had users pay third-party companies for features. I wrote the guidelines below, they are general enough to be applicable to most projects: Guidelines about sponsoring development In case you are willing to pay ...


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 ...


8

Submit a patch. (Or multiple patches.) Note in your submission that the patch makes breaking changes, so the maintainer can increment the version number, or whatever signal they use to notify downstream users of such changes. Make a fork with a different name (DasypusNG). Host your fork somewhere accessible to collaborators (GitLab, GitHub...) and somewhere ...


8

Of course there is no single answer to this question. The motivation can change over time and over individuals but I will try to list a few common reasons. For ideological reasons People who invented free software (RMS et al.) did it originally for very ideological reasons ("all software should be free" - that is, respect four fundamental freedoms) and ...


8

I'm not aware of any hard metrics that can be used to automatically count non-code contributions (and I'm not sure there could be one) but I do know about projects that (1) survey contribution types in volunteer collaborative communities centered around software development, with the specific goal of encouraging the recognition of non-code contributions, and ...


7

This of course varies from project to project, but yes: there are both businesses and freelancers who do this. But more so for large free software projects, than for small ones. As an example, look at a Drupal. Drupal is a FLOSS project (requiring all distributed components to be licensed under GPLv2+) that also sustains a large community of individual ...


7

An open source license is a grant from the copyright holder to someone else, giving them additional rights. If I give you the rights to version 2 of my work, I don't have to give you rights to use version 3 of my work, because it's mine. If version 2 is GPL, version 3 can be BSD licensed, closed source, or only available to Martians, that's up to me. Now, ...


7

As a project leader, for years I have tried to answer every single question coming to the mailing list of my user-oriented software, and I have found that: Many users can't read much English and don't have the skills to search/locate information efficiently Some users won't read the documentation even under torture Some users don't really trust the ...


7

Yes. To do so, you need to fork a project (thereby becoming the BDFL of that new project) and just simply have your fork be more popular than the original project. It's not really hard at all, especially if you happen to be a large corporation that is able to dedicate a lot of time and effort into the fork (much more time and effort than the existing BDFL ...


6

Answer to your first question, getting involved with an open source software is as easy as looking at the About section of your favorite software. There are loads and loads of open source software around and as a FOSS newbie, it's easy to get confused as to which one to pick and start working with. I'd suggest a software that you really care about and ...


6

Carefully selecting which changes are accepted, and which are rejected is one way that you control the direction of your project. Accept all submissions, and you'll end up with a mess, or at the very least, something you didn't envision. Of course, if you document the vision and goals of the project, it becomes easier for you to select submissions, and it ...


6

The first thing you should do is select a project. A good place to start would probably be a project you already use, or are at least passionate about. Second, I'd do some lurking - subscribe to the mailing list(s), and read a bit so you get the "vibe" of the community and get an initial feeling of what's acceptable and what's not, what kind of patches are ...


6

I think the question should be the other way around: How does people interested in Open Source development find you and your projects? My answer would be: be visible and provide easy ways to get engaged. Being visible means to have a good homepage which explains the project as good as possible, write about it on blogs, news pages, social networks, go to ...


6

My colleague at the Ballistic Research Laboratory, Mike Muuss, leader of the BRLCAD project (also well-known as the author of the "ping" network testing utility), was killed in an automobile accident. The BRLCAD project successfully continued as others picked up the reins. "ping" continues in use as a standard tool on most platforms, but I'm not aware of a ...


6

The typical project life cycle: build something that's useful, but buggy people start using your software because it is useful people are annoyed because your software is buggy, and is missing important features people are so annoyed that they just write you a pull request you now have a contributor the new contributor has the feature they wanted, and leave ...


5

You should try to use and offer the communication channels where your target audience - user and developers - resides. This might be the same channels, different ones, or there may be a certain overlap. You do not want to force any of them to use one particular channel, especially if they don't like it. But you do not want to force yourself to use an ...


5

You could charge the paying customers a small extra fee of a few percent for open source development. You can argument that without the community and their contributions the software would not exist in the current state and you want to pay back all the effort being put in. And while one user maybe can't afford to spend thousand dollars to get a feature ...


Only top voted, non community-wiki answers of a minimum length are eligible