At Lifehacker, my original vision was to create a new kind of tech blog, one that wasn't yet another "boys worshipping tech toys" site, one that was helpful, friendly, and welcoming versus snarky, sensational, and cutting. (That was no small task in the Gawker-verse, and I learned much in the process.) Today at ThinkUp, I have a similar goal. We encourage contributions not only by women, but open source newbies and non-usual suspects of all stripes: designers, user experience experts, writers, students, and enthusiastic users. We explicitly identify inclusiveness as one of the best characteristics of our small, up-and-coming community. Still, uptake is slow, the on-ramp steep, and for me, it constantly begs the question: what we can do better?

That's why an essay by UX designer Vitorio Miliano, Designers and Women in Open Source, caught my eye. Miliano theorizes that there aren't many designers in the open source world for the same reasons there aren't many women: because open source communities alienate non-coders and newbies by design. He writes:

I believe the problems with open source not being able to handle non-programmers in their projects is the same problem as the rampant sexism: open source culture is not feminist. Feminism is fundamentally about equality for everyone, not just women, and designers of any gender are just as alienated as women programmers, because it’s not an equally welcoming environment. There’s no perceived value in open source for mentoring, facilitation, disciplining of unruly users, training of newcomers or non-technical users, etc., which are needed to support both designers of any gender and women in any role.

That's a punch in the gut for OSS leaders who work hard, often in their spare time, to create a democratic process and collaborative workflow for total strangers located around the world to create something as complex and technical as software. (Especially those of us who identify as feminists.)

But Miliano's right. And as far as I can see, it's up to OSS leaders to work even harder to redesign their communities to encourage diversity instead of prevent it. Because it helps me to think aloud and write things out, here are some approaches we've implemented, discussed, or are considering at ThinkUp.

Welcome Wagons, Mentors, Conversion Rates, and the Power of Nice People

The best part about working on an open source project is that you're not just building a software application; you're building a community. In addition to making first-class software, ThinkUp's goal is to be the ultimate "gateway project," a friendly, accessible virtual neighborhood that people want to live in and build up, especially if they've never been a part of OSS before. One of my main metrics for measuring our success is how many community members' first-time OSS contribution happened at ThinkUp. We love handing out the Nerd Merit badge to first-time contributors.

Converting a newcomer into a contributor starts with a warm welcome.

At Lifehacker I learned something important about creating a productive online community: leaders set the tone by example. It's simple, really. When someone you don't know shows up on the mailing list or in IRC, you break out the welcome wagon, let them know you're happy they're here, show them around the place, help them with their question or problem, and let them know how they can give back to the community. Once you and your community leaders do that a few times, something magical happens: the newbie who you welcomed just a few weeks ago starts welcoming new folks, and the virtuous cycle continues.

We're still relatively small, but at ThinkUp we've done a good job of this so far. After two years, we pride ourselves on two things: 1. newbies are welcome, and 2. while we've had passionate conversations, we've never had a single flamewar or ego battle on our mailing lists.

Mentoring new contributors is also a powerful way to grow and diversify your community, and create long-term, loyal contributors. After last year's success in Google's Summer of Code mentoring program, we plan to do more mentoring/internship programs for new coders at ThinkUp. Creating bonds between new coders and veterans strengthens the community and attracts even more like-minded contributors who enjoy collaborative learning on a common project.

For coders, the path of promotion from user to contributor is clear-cut, but the on-ramp is not as obvious for non-developers. An early thread on ThinkUp's mailing list, subject line The frustration of a non-developer, began our community's clarification of what, exactly, constitutes a contribution to the software. Turns out, it's not just code.

Clarifying and Encouraging Non-Code Contributions

For programmers, the process of contributing to an open source project goes like this: you download the source code, you change the source code, and then you submit your changes to the project maintainers in the form of a patch, and if that patch gets accepted, your contribution shows up in the software. Done.

What's not clear is how people who don't code contribute their skills and expertise to making OSS software. Because it's not clear, they don't, and the software looks and feels like it was designed by engineers, for engineers—because it was.

At ThinkUp, there was a time that I was so focused on perfecting the right git branching strategy, I forgot that contribution does not always equal code. This is an area where we can still improve, because there are so many different ways non-coders can and should contribute to the project, including but not limited to:

• Showing up in the IRC channel and welcoming newcomers
• Offering tech support on the mailing list or in IRC
• Transferring knowledge shared on the mailing list or in IRC into the project wiki
• Following up on tech support questions on the mailing list or in IRC with further questions, links, or additional information
• Filing bugs in the issue tracker, or updating existing issues
• Taking screenshots and documenting details of confusing or clever bits of interface
• Recognizing good work by community members; discouraging unwanted behavior; acting like the kind of community member you want to work with
• Tweeting, blogging, or Facebooking about project news, developments, or features
• Hosting, showing up at, or blogging a project podcast
• Pairing up with a project "buddy" to work on an issue and brainstorm solutions
• Mocking up or wireframing interfaces for existing or desired features, even if it means using a tool as simple as Microsoft Paint

Sometimes turning a non-coder into a contributor is as easy as pointing them to a wiki page and asking them to add text about their experience using or troubleshooting the software, like Dan did here.

When an OSS community has a code-centric view of project contributions, not only does community, documentation, and technical support suffer—the software does as well.

Adjusting Community Values: Prioritizing Design and Usability

A well-built software application does more than just function: it's beautiful, frictionless, self-explanatory, and it performs a task and stays out of your way. Still, interface design doesn't get nearly the respect and prioritization it should by typical OSS engineers. (Myself included; this is another area where ThinkUp can improve.)

The solution isn't simply getting more designers and UX experts involved in open source, it's something much more difficult: changing community values around those skills. Miliano writes:

For a designer to contribute to an open source project, there would have to be developers committed to implementing the work, to work on “polish” and “froofy things” instead of “real features” and other “important things.” That’s a hard nut to swallow, and what volunteer project owner will ask all their volunteer contributors to, please, stop working on your pet projects within this codebase and let’s actually cut features and work on UI and usability and design?

When "polish" is a priority, when it's discussed, recognized, rewarded, solicited, and it's a required part of the patch acceptance process, programmers will be motivated to do the work to get it right. The key here is to prioritize design and usability upfront, rather than accept a mess of software with plans to slap a pretty veneer on afterwards. This is been the lesson I keep having to learn and re-learn: design and usability cannot be an afterthought.

Cutting features in the name of usability is an especially sticky wicket when those features were built by volunteers in their spare time, but this is where project leadership steps up.

Design by Committee and the Benevolent Dictator

Feature/option bloat is a common pitfall for all software, but it's especially so for open source software built by a democratic community of self-starting engineers for whom it's too easy to say "I'll just hack up a little button that adds my pet feature and stick it here." Every OSS project has a single committer or team of committers who have final say about what features and fixes get merged into the application. Some projects have a Benevolent Dictator, who has final say on decisions that the community can't reach consensus on. It's the committers' and the BD's role to ensure that end users come first and engineer's pet projects come second.

However, good project leaders don't rule with an iron fist; rather they sell a vision for the software and its priorities to the community so that the community comes to good decisions on its own. When it cannot reach consensus, the BD steps in. Karl Fogel explains:

Although "benevolent dictator" (or BD)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

Because an OSS project's BD is not actually a dictator with swift and final say on all decisions, these community decision-making processes can take months and even years. After his logo design was rejected after a year of discussion by contributors to an open source project, Miliano says that on a non-OSS team, the contributors who spoke up wouldn't have had a say at all:

I would wager that as most of the developers of any given open source project are not representative of its end-users, the developers wouldn’t even be involved in the design process in the first place. You can’t design by committee, only take into account the needs of the stakeholders, and if you don’t actually use the software, you might not be at that table. The designer would, essentially, only be generating work for them.

I think there's an in-between here, and at ThinkUp, we're still finding it. We're working with Mule Design to redesign the app's look and feel and interface. While we're only at the beginning of that process, in the kickoff we decided that design by committee was not an option. The community will not vote on a list of design options. Instead, Mule will create a design and sell it to the community at large, citing what they learned about the app from its stakeholder and end-user research. To keep the community informed along the way and encourage buy-in on the process, they'll share what they learned and what they made as they reach milestones. Because Expert Labs funds ThinkUp development, contracted Mule, and acts as ThinkUp's benevolent dictator, there is no question: we will implement Mule's redesign with community buy-in—even if everyone doesn't agree on every single pixel.

Your Community Is Your Best Feature

On the modern web, where far-flung strangers collaborate on things like authoring an encyclopedia and overthrowing abusive governments, it's still too hard for most people to contribute to open source projects. It's ironic, too, because open source collaboration was happening on the internet way before tools like Facebook, wikis, Twitter, and Google Docs existed. It's not for lack of tools, it's because of broken culture. Miliano writes:

Open source platforms are a community in the traditional sense of something you pretty much have to be internally motivated to join. Joining an open source community is closer to joining a church or moving into a neighborhood, and, let’s be honest, these neighborhoods are sexist boy’s clubs with no facility for mentoring, no respect for design, and mailing lists that are 50% dick-measuring contests.

But that's not the way it has to be. If OSS projects do what it takes to welcome contributors of all stripes, not just the usual suspects, they'll produce better software. At least, that's our bet.

Expert Labs is offering a new iPad 2 (16GB, Wi-Fi only) to a community member who makes a significant contribution in the next month and a half. Here's how it will work:

• Developers get 4 weeks to issue a GitHub pull request for a new ThinkUp feature or fix of their choice (by April 6th); plus another 2 weeks (April 20) to get that code reviewed, accepted and merged into master. As always, tests must be included in your patch submissions, and all code must comply with our style guide.
• After all the submissions are in, the developer will post screenshots or a screencast plus an explanation of what the new feature/fix adds to the project on the mailing list. The community will then vote on what their favorite new feature or fix is. With the community's help, Expert Labs' employees (Gina, Anil, and Andy) will determine the iPad winner. 
• The developer who has the feature which was both merged and deemed most useful gets a brand spanking new iPad 2. Expert Labs will cover international shipping, and we'll do our best to order the iPad in your local Apple Store; if not, we'll ship you a U.S., WiFi-only version from the States.

What should you build? Here are a few ideas:

• Create a new new data visualization that displays post statistics, analysis, or information in a useful way
• Create a JSON API for ThinkUp post replies (Issue #565)
• Improve the ThinkUp Facebook plugin so it offers the same features as the Twitter plugin does
• Create a mobile CSS stylesheet to make ThinkUp easy to use on an iPhone or other smartphone
• Create a Bit.ly plugin which stores click count statistics in ThinkUp's link database, and add a list of most-clicked links for a ThinkUp account (Issue #354)
• Create an email invitation system so it's easy to invite people to register on a TU install without having to open registration to all (Issue #42)
• Redesign ThinkUp's user page to use the standard dashboard/post page template (Issue #256)
• Add the ability to see replies from multiple posts in one view (Issue #407)

These are just a few ideas. If there's something else you're inspired to work on, go with it. But remember, to win the iPad you've got to wow the community with your work and be able to sell use cases when you post your submission to the list.

Not a developer? Here are some ways you can get yourself that iPad:

• Make a killer screencast of ThinkUp features or use cases
• Draft new documentation or improve existing pages on the ThinkUp wiki with complete, well-annotated screenshots and clear, step-by-step instructions
• Mock up a new and improved thinkupapp.com which sells ThinkUp and makes it easier for visitors to understand and get started using
• Mock up a new visualization of ThinkUp data

This is our first time doing a bounty like this, so let us know if you have any questions on the ThinkUp mailing list. Can't wait to see April's submissions. Good luck!

Cross-posted to the Expert Labs blog

GPL communities are open and embracing of other GPL developers, but generally off-putting to liberal-license and closed-license developers. [...] Many GPL developers take comfort in the fact that their hard work can’t be quietly taken and incorporated into a commercial product, without any payback of time or money to the original project. But you’re piloting an open source project, and the first step of building a community is to get people in the door. [...] If you operate from the presumption that great developers love to build great projects, the first step in any successful open source project is to get as many great developers in the door as possible.

Jalkut's right about one thing: Great developers do love to build great projects. He may be right about another: Some developers may have to pass on using GPL code because they're not willing or able to share-alike their changes to it. But the one really attractive part of using the GPL that he's missing is this: Great developers love to build projects that more people will use. The GPL is my software license of choice because "share and share alike" spreads the impact of my work. What motivates great individual developers isn't always money, it's ego.

Using the GPL, I know my time and effort will reverberate down through every iteration of the project. More developers and people will be free to use it and its children, cousins, grandchildren and great-grandchildren. There's really nothing more satisfying than seeing software you wrote and made free become something better--that's also free.

GPL-licensed WordPress lead Matt Mullenweg says he believes the GPL is "the most moral of the open source licenses." He explains:

It’s user freedom that the GPL was created to protect, just like the Bill of Rights was created to protect the people, not the President. The GPL introduces checks and balances into an incredibly imbalanced power dynamic, that between a developer and his/her product’s users. The only thing the GPL says you can’t do is take away the rights of your users in your work or something derived from a GPL project, that the user rights are unalienable. You are free to do pretty much whatever you want as long as it does not infringe on the freedoms of others. (Sound familiar?)

Of course, this OSS license holy war has been raging for years, and I'm not as well-versed about the differences between the GPL (and all its versions), BSD, Apache, MIT, and other licenses as I should be. That said, based on the knowledge and experience I do have, I'm with Matt. As far as I can see, the GPL does not stifle community. To the contrary, GPL builds it precisely because none of the forks of a GPL-licensed project road are a dead end: everyone can join in, on the same terms, at any point, and contribute to its progress.

The practical ones:

• I'm a heavy Gmail user, and Android offers up-to-the-second push Gmail, and a Gmail interface that far surpasses Mail on the iPhone. Reading, searching, labeling, and otherwise processing my email is the most important thing I need to do on my smartphone besides make calls, and it's simply easier in Android.
• Android lets me manage my contacts in one place: Gmail, and syncs them automatically to my phone. No more local address book!
• Android is better than the iPhone software in a few ways: it's way more customizable, it offers copy and paste, the pull-down "window shade" is a better notification mechanism, and in general it gives you that feeling that you're in control of every setting.
• Android doesn't run Safari, but it will likely run Chrome someday.
• I love the trackball on the G1 for scrolling and clicking. From an economy-of-motion standpoint, it's a way more efficient way to interact with the device than swiping and tapping the screen. The snap-out keyboard is sweet, too.

The philosophical reasons:

• Android is open source.
• Because it's open source, many of my favorite open source apps work with it and not the iPhone yet, like KeePass, for example. (See KeePassDroid.)
• Android's apps are written in Java, and as a Java developer, this delights me.
• Android doesn't tie me to iTunes, which is a fine piece of software, but is just a little too bossy and proprietary-like for my taste.

Obviously, your mileage may vary. But there is a misconception that the iPhone is a superior smartphone, and that's not necessarily true. What's true: The iPhone software has been out longer than Android, so it may be more fully-baked (though apps and Safari crash on my iPhone regularly, more so in the 2.0 "upgrade"). The iPhone has a much larger market share. There are probably more apps for the iPhone than for Android, but the Android Market is well-stocked, and I have had little trouble finding the stuff I need. The only iPhone thing I truly miss is its built-in visual voicemail, but I've installed PF Voicemail+ on Android to get that same functionality. Not being a heavy voicemail user, this isn't that big of a deal to me (though it may be for you). Update: I also miss the excellent Evernote iPhone app, and have my fingers crossed in hope an Evernote equivalent will happen soon (or at least a mobile Evernote site that works well in a mobile browser).

Most likely I'll remain in the minority as a G1 owner, but you know what? In a sea of iPhone-toters, I'll enjoy actually "thinking different."