Several weeks ago, I shared some initial thoughts about how hearing “Alive and Kicking“ by Simple Minds reminded me how vital emotional connection is not just in the music I listen to, but in the open-source software I create, too. Now with some further reflection, I can see there’s more to explore here.

In open-source, we still too often default to initially only competitive comparisons and technical feature lists. With growing concerns about contributor burnout, project sustainability, and community accessibility, we can't lose sight of emotional aspects - like making our projects feel welcoming rather than just functional?

Here are eight practical guidelines I’ve developed through building and learning from the Docsify-This project - focusing not just on what we communicate, but on what we actually create:

Lead with transformation, not features Instead of “Remote Markdown rendering with customizable URL parameters,“ try something like “Turn any GitHub file into a styled webpage in seconds - just paste the URL.“ People connect with outcomes, not specs.

Acknowledge contributors as collaborators Changelog entries can sometimes include “with thanks and appreciation to...“ Contributors aren't just code submitters - everyone engaging with the project can be co-creators helping to shape what comes next.

Assume success in your language “When you...“ instead of “If you want to...“ It’s subtle but conveys confidence rather than uncertainty - for both users trying features and contributors proposing changes.

Acknowledge pain points with empathy

“Tired of setting up entire websites just to share documentation?“ hits differently than “Docsify-This requires no setup.“ Show understanding before offering solutions, whether for user frustrations or contributor friction.

Create moments of delight When possible, provide an impactful moment in any public demo of your project, like with Docsify-This how pasting a URL seems to almost magically transform a bunch of Markdown into a styled Webpage. Little touches that can make people smile - from seasonal emojis in version headers to thoughtful error messages that help guide users to success.

Iterate in public Share works-in-progress and invite feedback during development, not just major release milestones. For example, use social media to share meaningful “sneak peeks“ of upcoming features and preview builds, inviting feedback from the community. This transparency makes people feel invested in the project’s evolution rather than just consumers.

Share your origin story

Project READMEs that highlight core philosophies and founding design principles help people understand your motivation - why you built this particular solution rather than just another tool in the same category.

Make belonging feel natural Use inclusive phrases like “you’ll be able to...“ and “join the…“ in your project documentation rather than distanced language about what "users can do." This extends to social media updates that focus on what you're building rather than criticizing what others have built.

Ultimately, the question that drives my development philosophy: Can people love their web publishing tool the way they love a favourite song? That emotional connection - for users and contributors alike - is what transforms good software into something people actually want to engage with and share with others. These approaches work best alongside the basics: solid functionality, effective documentation, and good project management.

❓How have you seen open-source projects create a positive vibe? Feel free to share your feedback or comments.