If you have ideas/topics missing: tell me!

[bagder]

I am convinced there are topics, questions and areas of Open Source this document should include but does not yet because I have not thought about.

Tell me: what do you think I should include?

[stanimirovv]

Personal wishlist:

• How important are metrics like code coverage / code quality, etc
• Each point here: https://github.com/bagder/how-hard-can-it-be/blob/main/start/attract.md probablly can be a chapter i.e. - how to make a low entry barier for contributions without compromising quality ? How do you promote a project and get a bit of traction ? How do you continuously keep yoursel up to the high standards when you are a solo developer ?
• Aditionally maybe it is useful to touch on the topic how to contribute to open source projects i.e. what is the perfect contribution to you from the point of view of the maintainer ? Tested and well documented are the first few things that come to my mind

[bagder]

Excellent points, thanks. I''l make sure to come back here later and make sure I cover these. I'm still adding and polishing content all over...

[bagder]

I believe those topics are now at least partly covered.

[stanimirovv]

@bagder Yep, awesome work on the book - it really is a treasuretrove of useful things.

For example the code quality is a very nice, small wrap up of a very complex topic.

[probonopd]

Thanks for your collected wisdom @bagder. This is truly great advice.

Maybe you could consider recommending the use of forums like this one instead of mailing lists.

• Mailing lists require you to sign up in a cumbersome process
• Mailing lists "spam" you with many mails about subjects you have no interest in. I only want notifications about this issue that I reported, not about everything
• Mailing lists expose your mail address
• Mailing lists don't let you edit your posts

Whereas forums, like this one, lower the barriers to participation a lot.

• You don't have to sign up, you can use your existing GitHub account that you are already using for everything else
• You don't get "spammed"
• Your mail address is not exposed
• You can edit your posts retroactively if you made a mistake or have new information

Here is the discussion that triggered this suggestion:

• fusermount, fusermount3,... fusermountN compatibility guarantees?  libfuse/libfuse#670 (comment)

No, I am not going through the trouble of joining a mailing list to ask a question.

[probonopd]

Every time I encounter a mailing list, it feels to me like an open source project doesn't want drive-by contributions. I'd really be interested to learn what the pros of mailing lists are supposed to be nowadays.

[bagder]

I'm the lead developer of curl. We use mailing lists as our primary means of project communications since the very beginning. I think it has worked well, and it keeps working well. If someone can't even be bothered to subscribe, then usually that's not a very committed or engaged person so maybe that's not such a big loss. There are many striving projects run mainly via mailing lists. And of course many that don't have one at all and that are run completely via other communication means. That's why I maintain that the exact method of communication is not what decides if you succeed or not.

The pros of mailing lists are the same as they always were, including the ability to use your own client, collect all communication in a single spot etc. I still subscribe to 100+ mailing lists, I would never be able to participate conveniently in 100 forums.

[probonopd]

If someone can't even be bothered to subscribe, then usually that's not a very committed or engaged person so maybe that's not such a big loss.

With the highest respect for curl and for your work, isn't that an antipattern if you think about it? This line of thinking is what it makes it much easier to participate in smaller projects (like badger) than in larger/older ones (like curl). With some of the most central projects deep down in the stack (the likes of glibc) it's imho the worst. An then they wonder why no one contributes.

Just food for thought.

[bagder]

I don't think that is a universal and objective truth, that's just your view. I personally often find projects that have established mailing lists to be much easier to contact and discuss matters on/with than those that for example stick to just having a presence on GitHub.

[gevaerts]

Maybe pointing out that different people have different preferences would be useful?

[probonopd]

Maybe you should advise people to use Semantic Versioning and to avoid binary compatibility breaking changes at all cost. In case compatibility breaking changes are not avoidable, the old major version should be continued to be shipped alongside the new major version until the oldest still-supported distribution carries the new major version.

Here are the discussions that triggered this suggestion:

• Please follow semantic versioning openssl/openssl#5042
• https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965636