public VCS, just tarballs Lack of exposure * This is something that only builds with time/influence * POLITELY get it in front of other more prominent members
public VCS, just tarballs Lack of exposure Lack of support channels No place to report issues * I’d never used a real bugtracker, because LOLcollege * SourceForge was still hot, so you know this is antiquity * And it was PHP, just before Zend Framework, CakePHP & the others came out.
decent usage ~1.9k GH stars 136k PyPI downloads * 1.5 years later, now it was time to tackle RESTful APIs... * Applied the same approach, to a different outcome.
docs On GitHub within 2 weeks of initial commits IRC + mailing list Announced to others * Twitter announcements fueled a lot of initial interest * Other people started talking about them
docs On GitHub within 2 weeks of initial commits IRC + mailing list Announced to others Had its own site/domain * Don’t underestimate a vanity URL * Promise a designer favors (or better yet, get them using your stuff so they feel obligated to help)
This often falls out of the software itself, as it was built for a purpose * But be warned that some users will have other ideas about how to use it * Accommodating (most) everyone puts you in a better position * Fewer hostile forks
come. * Except for rare situations (absolute need or so sexy!), without this, no one will use it * Case in point: It’s why many of you know about Flask but virtually no one knows about Itty * Lack of docs means most people will get frustrated & move on
with focus * People want to know it’s actively developed on, what the future holds, how to get help, how they can help * IRC * Mailing lists * Website * Twitter
Users need a forum in which they can voice their issues, their needs, where they find shortcomings, what they’d love to see * Lots of good ideas * Sometimes lots of bad ideas * Separate the wheat from the chaff, but do it NICELY * Ticket trackers * Spend time chatting with the heavy-duty users as well as the newbies
will use it. * Again, people want to see active development * Everyone dreads the creaky old library no one has given any love & could break at any moment * Should feel like a celebration, both for you & for the community
should consider yourself a success when you acquire haters * Remember there are lots of happy people who are quietly using the software * I’m super-thin-skinned, so I struggle with this one nightly
this, trying to provide support at all hours, even late at night * You burn-out very, very quickly * If they're not paying you, you don't owe them * You need to reserve time for yourself
you even start feeling like you're behind, it's time to get help * This isn't as easy as it sounds * Addressing quality/style/commit style/attribution/triage/etc.
not enough to just have technical documentation * You actually need community documentation as well * LICENSE, AUTHORS * Standards for code * Steps to filing an issue * Steps to creating a patch/pull request * Possibly a style guide?
aren't staring at your repo all day * Make it easy for them to get the information they need * Blog posts * Mailing list announcements * Tweets * Et cetera * Responsiveness in tickets as well
so guilty of this. * Let go sooner * If a major bug fix lands or there's a new feature, push it out the door * Don't wait for something that's "big enough"
stumbled on from Google. * Remember that they're likely not an expert * They likely don't know the codebase * Just like you, they probably just want things to work so they can get on with their day
daniellindsley
taichinakamura
fujisawaryohei
knih
z63d
tomoki10
tsukuha
yositosi
champ
rmakiyama
handy
sat
bengo4com
pauljervisheath
addyosmani
afnizarnur
iamctodd
denniskardys
lemiorhan
sergeychernyshev
smashingmag
soudai
scottboms
lara
rasmusluckow
