A piece over on Fedora Magazine, following a talk I did at Flock this summer. The short version: open source projects need all the help they can get spreading the word. Fedora, Apache projects, GNU projects, Debian, etc., all depend on word of mouth to reach users. By reaching users, we find new contributors, and it’s the new contributors that help keep projects going and reaching new users. We don’t have megabucks to throw at ad campaigns, but we have millions of users–and the impact would be enormous if even 10% of those users spent a little time spreading the word about Fedora (or other project).
More users means more contributors. More contributors equals better projects. Better projects mean more users, and fewer people choosing proprietary solutions. Don’t wait for somebody else to spread the word, jump in and lend a hand.
The marketing group was a bit disorganized in the F23 cycle, and we can do much better. I hope to do more in the F24 cycle, but I can’t do it alone, and don’t really want to! So if you want to see Fedora succeed wildly, I hope you’ll find a way to join our efforts. Read the full piece on Fedora Magazine, and feel free to ask if you need help jumping in!
One of the things I use social media for is to put the word out about projects that I work with/on and to draw attention to events or things that might be of interest.
Likewise, a lot of my friends are in a similar position. Whenever I peek into Twitter, Google+, or Facebook, I try to re-share/amplify things that my friends post that might be of interest to people who follow me or are connected to me on social media. This used to be sort of de rigueur for social media, but I’ve noticed that the practice has fallen way off.
Assuming your friends are posting things that might be of interest, you might consider boosting their signal a little and help to spread the word. I generally try to RT or promote other people’s events, posts/articles, and so forth at least as much as my own. And if I notice someone being kind to me on social media, I try to return the favor. (Note, this is not a request that everyone all become retweetbots or anything — just asking for folks to take a second and help promote other folks’ stuff as much as they pimp their own.)
The nice thing is that you have a chance to be exposed to things outside your own network, and I’ve run into a lot of interesting things, articles, and people that way.
Thoughts, comments, flames?
Please excuse the garbled proverb, I don’t mean to say that people in Rome shouldn’t use GitHub. Instead, I’m talking about using the right tool for the job and the community. Sometimes the “right” tool is completely wrong, because the audience is wrong for the tool.
Collaboration works well when you use the right tools. For developers, that’s often git and GitHub. Wanna work on some code? Throw it up on GitHub. Check out the code, make your changes, and commit. Most developers working in open source today are likely to know git well enough to work with you. (Note that I’m using “GitHub” as shorthand for any git repository/service, really.)
At the edges of developer communities, though, there’s a temptation to use developer tools for non-development work. For example, creating marketing materials and documentation.
For some documentation projects, git is probably the right tool. Especially if you’re doing books and trying to document along with a release cycle. But for creating marketing materials or “living” documents that change a lot? Probably not such a great idea.
Use the tools that are lightweight and easy for anyone to work with, preferably something browser-based and that allows revision control. (e.g., a wiki.) While there are flaws with those tools, they’re “good enough” and – most importantly – they pass the “native” test for people who are contributing to non-code projects. Do they have a browser? Check. Can they figure out how to use the wiki in 5 minutes? Check. Do they need to create an account with a third party service or download a tool they wouldn’t otherwise need? Nope. All good.
Resist the urge to impose your favorite tools on an unsuitable audience. It’s always tempting to go with what you know best or optimize for your own use case, but resist the urge when it’s going to be detrimental to getting maximum participation and building community.