4 ms·

This can entirely depend on the type of project and how many active contributors there are - if you have a lot of contributors then you may find more cross-user

This can entirely depend on the type of project and how many active contributors there are - if you have a lot of contributors then you may find more cross-user communications in which case gitter really does help (they answer each others' questions). If there are just a few people able to answer questions or just one (you), then using issues as Q&A would be good enough for now. The latter is quite common with apps rather than libraries. It is also more searchable which helps others. Curious to know, how are you defining small community? I see you have ~100 watchers, ~900 stars, ~200 forks. Are you basing it on that, or some other criteria (# issues per week etc) My project - I have a project with roughly same numbers as you. I did set up a gitter but everyone ignored it and emails me directly or just uses the issues. Despite not being actual issues, and despite its awkwardness, it's back to what I said earlier - searchable for people with similar problems in the future. I'll be sticking to issues until I reach hyper-popularity and then the gitter may revive itself.

sanxiyn 9y ago
I see 19 contributors, which do look small.
- mabynogy 9y ago
  19 is very good. Recruiting active contributors is extremely difficult.
  - fundamental 9y ago
    Boy oh boy is that an understatement. One of the ~15 year old ~70kloc projects I help maintain only has a handful of active contributors at any point. Even with efforts put into marketing it there's not a large pool of people to pull from. I wish there was a formula for making things more attractive to contribute to (in both the short and long term), but it's a fiddly process.
    - mabynogy 9y ago
      > I wish there was a formula for making things more attractive to contribute to (in both the short and long term), but it's a fiddly process. I'm trying to elaborate something for that. On way I see is to reduce the entry level as much as possible. I deduce that a project aiming a lot of contributors should be heterogeneous (contributors can choose their favorite language)and shouldn't have a single build system (interfaces exists at runtime with a middleware, vms, or files).
      - fundamental 9y ago
        That might work or it could backfire. With more build systems and more languages, then you can easily end up in the category that someone needs to know all of them to make meaningful changes. If you have people staying in their own part of the codebase it's easy to imagine significant bitrot occurring over time.
        mabynogy 9y ago
        I imagine software isolated in vms. Many people could do the same thing or overlap with someone's else project. It would allow projects to compete.
        fundamental 9y ago
        Interesting. That's a radically different view on what a project should strive for than my own. My own FLOSS work focuses on getting work closer to the system's metal in order to have a responsive low-latency/realtime configuration (realtime being in the realtime signal processing sense). In this area in particular people doing the same things results in reasonable breadth of work, but insufficient depth. So plenty of options, but all of them not good enough to compete with larger development teams.
        mabynogy 9y ago
        I've seen your website. It's really fascinating.
  - imtringued 9y ago
    Unfortunately in this case only 3 of them are active contributors.
    - mabynogy 9y ago
      What is that project?

sanxiyn 9y ago

I see 19 contributors, which do look small.

mabynogy 9y ago
19 is very good. Recruiting active contributors is extremely difficult.
- fundamental 9y ago
  Boy oh boy is that an understatement. One of the ~15 year old ~70kloc projects I help maintain only has a handful of active contributors at any point. Even with efforts put into marketing it there's not a large pool of people to pull from. I wish there was a formula for making things more attractive to contribute to (in both the short and long term), but it's a fiddly process.
  - mabynogy 9y ago
    > I wish there was a formula for making things more attractive to contribute to (in both the short and long term), but it's a fiddly process. I'm trying to elaborate something for that. On way I see is to reduce the entry level as much as possible. I deduce that a project aiming a lot of contributors should be heterogeneous (contributors can choose their favorite language)and shouldn't have a single build system (interfaces exists at runtime with a middleware, vms, or files).
    - fundamental 9y ago
      That might work or it could backfire. With more build systems and more languages, then you can easily end up in the category that someone needs to know all of them to make meaningful changes. If you have people staying in their own part of the codebase it's easy to imagine significant bitrot occurring over time.
      - mabynogy 9y ago
        I imagine software isolated in vms. Many people could do the same thing or overlap with someone's else project. It would allow projects to compete.
        fundamental 9y ago
        Interesting. That's a radically different view on what a project should strive for than my own. My own FLOSS work focuses on getting work closer to the system's metal in order to have a responsive low-latency/realtime configuration (realtime being in the realtime signal processing sense). In this area in particular people doing the same things results in reasonable breadth of work, but insufficient depth. So plenty of options, but all of them not good enough to compete with larger development teams.
        mabynogy 9y ago
        I've seen your website. It's really fascinating.
- imtringued 9y ago
  Unfortunately in this case only 3 of them are active contributors.
  - mabynogy 9y ago
    What is that project?