Unsolicited software evangelism guidelines discourage feature-based promotion without request

The material outlines a critique of unsolicited software evangelism, positioning it as a recurring source of friction in online technical discussions. The core argument is that promoting alternatives without explicit request or context wastes time and undermines trust. This is particularly relevant in engineering spaces where tool selection often hinges on specific requirements, not just general awareness. The guidelines suggest that evangelism should be reserved for scenarios where the recipient has actively sought recommendations, rather than inferred or assumed needs.

A key cost of uninvited evangelism is the mismatch between the promoted software and the user’s actual requirements. The material emphasizes that feature parity is non-negotiable: if a tool lacks critical functionality, it is not a viable alternative, regardless of future potential or open-source contributions. This challenges the common justification of “patches welcome,” which assumes users have the time, skill, or inclination to contribute. For engineers, this underscores the importance of understanding the problem domain before advocating solutions, rather than defaulting to ideological or technical preferences.

The guidelines also address the role of user experience in software adoption. Evangelism that dismisses or undervalues UX, such as labeling widely used features as “anti-features” or “attention-grabbing garbage”, is framed as self-defeating. This reflects a broader tension in engineering culture: the trade-off between technical purity and usability. The material argues that polished UX is not a luxury but a requirement, particularly for tools aimed at non-technical users. For engineers, this highlights the need to balance advocacy with empathy for the end user’s workflow and expectations.

The critique extends to the motivations behind evangelism, particularly when driven by dislike for incumbent tools rather than the merits of the alternative. This can lead to recommendations that ignore or disparage features users rely on, further alienating the audience. The material suggests that such evangelism often backfires, as it signals a disconnect between the promoter’s values and the user’s needs. For engineers, this serves as a reminder that tool advocacy should be grounded in problem-solving, not personal grievances or nostalgia.