How do you find FOSS contributors
Just wanted to kick around the ball on how people find collaborators in their FOSS projects. And also how to make it more popular.
I overall have a hard time converting a small fraction of users of an application into FOSS collaborators. It's curious that for libraries it appears to be easier, probably because the users themselves in this case are necessarily developers, which can not be the case in desktop applications.
I overall have a hard time converting a small fraction of users of an application into FOSS collaborators. It's curious that for libraries it appears to be easier, probably because the users themselves in this case are necessarily developers, which can not be the case in desktop applications.
Yeah, I don't think you can expect users with no programming skills to contribute code to a FOSS project. They might not even know (or care) what FOSS is.
I think it's much more likely that a programmer starts to contribute to a project that he or she uses frequently and has feelings for and wants to see improved. Another reason, that is no different from non-FOSS projects, is if someone pays them to contribute. For example, an employee might be paid to write code for a FOSS-project because it's important for the company. Maybe it's a library that they use, maybe it's a compiler feature that they need, or maybe they need support for a certain platform that they want to ship on. A more concrete example is Intel contributing to the GCC and Linux projects probably because it's in their interest that they work well with their hardware.
Otherwise I think the easiest way to contribute (for both programmers and non-programmers) is probably to report bugs. I would imagine this to be a natural first step before becoming more involved in a project.
I think it's much more likely that a programmer starts to contribute to a project that he or she uses frequently and has feelings for and wants to see improved. Another reason, that is no different from non-FOSS projects, is if someone pays them to contribute. For example, an employee might be paid to write code for a FOSS-project because it's important for the company. Maybe it's a library that they use, maybe it's a compiler feature that they need, or maybe they need support for a certain platform that they want to ship on. A more concrete example is Intel contributing to the GCC and Linux projects probably because it's in their interest that they work well with their hardware.
Otherwise I think the easiest way to contribute (for both programmers and non-programmers) is probably to report bugs. I would imagine this to be a natural first step before becoming more involved in a project.
Last edited on
Bug reports and documentation are acceptable forms of contribution.
On the subject of bug reports, any idea how to more clearly explain how to write good bug reports to non-developer audience (or just in general). Like, I see people who write clearly what is the problem, give me a minimal small project that reproduces the error and other really nice things. But at the same time some users just write an angry "I had lots of errors" without explaining/giving at least the text, or a screenshot of the error and then when asking for more information they never answer.
On the subject of bug reports, any idea how to more clearly explain how to write good bug reports to non-developer audience (or just in general). Like, I see people who write clearly what is the problem, give me a minimal small project that reproduces the error and other really nice things. But at the same time some users just write an angry "I had lots of errors" without explaining/giving at least the text, or a screenshot of the error and then when asking for more information they never answer.
A user leaving a useless bug report is not something that's preventable, but it may help to explain to your users when they're about to enter one that:
* A bug report field is not a complaints box. It's not a place where you go to vent your frustrations, it's where you go when you want to help make the software better.
* If the user takes the time to make a quality bug report, the developer will take the time to attempt to fix it. I.e. the user must not believe that the time spent making the report is going to be wasted. In this sense, resolving a lot of issues as WONTFIX can be detrimental to the project.
* Resolving an issue sometimes requires some back-and-forth between the developer and the user, especially if the issue is hard to reproduce. The user should be able and willing to engage in that exchange.
* A bug report field is not a complaints box. It's not a place where you go to vent your frustrations, it's where you go when you want to help make the software better.
* If the user takes the time to make a quality bug report, the developer will take the time to attempt to fix it. I.e. the user must not believe that the time spent making the report is going to be wasted. In this sense, resolving a lot of issues as WONTFIX can be detrimental to the project.
* Resolving an issue sometimes requires some back-and-forth between the developer and the user, especially if the issue is hard to reproduce. The user should be able and willing to engage in that exchange.
Topic archived. No new replies allowed.