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
fujiwara3
kakehashi
bbqallstars
kenjikondobai
asei
nikkei_engineer_recruiting
mikit
lycorp_recruit_jp
kitsuya0828
oracle4engineer
uhyo
linyows
chriscoyier
bcantrill
jrom
eileencodes
ddemaree
addyosmani
andyhume
brettharned
mza
csswizardry
akosma
sferik
