May 13th, 2009

What do you want for free? Do users have to pay up to complain?

Posted by Joe Brockmeier @ 8:18 am

Categories: Building Community

Tags: Twitter, Asay, Linux, Open Source, Operating Systems, Software, Joe Brockmeier

Matt Asay excorates the whining masses that are taking Twitter to task for its ill-considered removal of the @replies feature. Asay says “pay money so that you actually have the right to voice your displeasure as a customer rather than as a user.” However, Asay misses a glaringly obvious point here — Twitter hasn’t given anybody the ability to pay up.

In general, I do agree with Asay that being a user isn’t enough to give someone the right to complain — or, at least, the right to be taken seriously. For open source projects, there needs to be some kind of consideration before taking a seat at the table — either as a contributor or customer. If you’re putting in sweat equity to a project, rather than cold hard cash, you should be taken seriously.

And, of course, money talks: Customers should expect their complaints to be heard, and acted on when possible and practical.

But the folks at Twitter are still finding their way, and the only option users have is to be loud in the hopes of being heard — or using alternate services like identi.ca which puts the power in the hands of its community directly. While Twitter is still trying to figure out what it wants to be when it grows up, its community doesn’t have the opportunity to “pay up” — either in contributions or money.

Right now, the only business that Twitter seems to be in is building out its user base: Which makes the complaints of its community quite valid indeed, whether or not they’ve sent a check. Depending on what business model Twitter ultimately chooses, just being an active user may be a valuable contribution in and of itself. (Assuming Twitter goes with some kind of advertising model.)

Asay’s suggestion that a predictable service is a premium business model leaves me a bit cold. Enterprise Linux distros have very little in common with Twitter, and the expectations for enterprise OSes are rather different than those for a microblogging service.

Right now, Twitter has something which Identi.ca doesn’t yet have: Momentum. But if the service continues to futz with the service and treating users like an afterthought, that may change.

May 7th, 2009

Using selfishness to put crowds to work for you

Posted by Joe Brockmeier @ 4:06 pm

Categories: Building Community, Collaboration

Tags: Stock, Documentation, Derek Powazek, Open Source, Investment, Finance, Joe Brockmeier

How do you enable “the wisdom of crowds”? Part of the power of community is that a group of people can solve problems much more easily than individuals, but only if you can provide tools that make it possible for them to do so and appeal to their own interests.

Derek Powazek has an interesting post over on A List Apart that details some of the components necessary for “a crowd to be wise.” According to Powazek, you have to have simplicity, a clean interface, aggregation, and a group of people who are thinking about their own needs:

It’s counter-intuitive, but the wisest crowds are the ones made up of individuals who are thinking about their own needs, not the needs of the group. In the stock market, the participants are all motivated to buy low and sell high. Yet the markets are usually wise about finding the value of a company. Each person is thinking about their bottom line, not the health of the company or the market, but it works.

Similarly, website creators were not consciously voting for certain sites to be highly ranked, but the collective linking decisions did produce wise results. Nowadays, link spammers do try to manipulate Google’s results, which is akin to stock manipulation. Both practices are fought by the institutions that depend on unmanipulated results.

Altruism is all well and good, but people are usually much more motivated by their own interests than the interests of others. This is one reason why open source code is usually so much better than the documentation that accompanies it (unless someone is paid to produce the docs): People contribute code because they want to use the code. People write open source documentation, typically, for altruistic purposes. Which is why many documentation projects flounder — the documentation does the writer little to no good, as they’re unlikely to read it again.

Code, however, is continually useful, because it’s often produced for “selfish” purposes.

If you’re wondering how to drive participation in a project: Whether it’s an open source project, a collaborative Web site, or some other endeavor don’t think about what’s in it for you: Think about what’s in it for them. When you can find a way to let the crowd scratch their own itches, and provide the necessary tools to do so, you’re on the road to success.

April 30th, 2009

Miro puts code up for adoption

Posted by Joe Brockmeier @ 4:36 am

Categories: Building Community

Tags: Internet TV, Code, Video, Miro, Corporate Communications, Marketing, Joe Brockmeier

I’ve heard of “orphaned” code, but this is a new one. The Miro project is trying a new approach to funding: asking enthusiasts to “adopt” lines of code.

From the letter to adopters on the site:

We’re a small non-profit in a sea of big budget, for-profit competitors, and the recent stock market crash has severely hurt the foundations that fund the bulk of our work. But we want to take this crisis and use it as an opportunity to flip our funding model on its head. If enough of our users adopt lines of Miro code, we can create an organization that is funded from the bottom-up and not dependent on the top-down.

We aren’t here to make money, we’re here for a mission: to distribute wonderful video around the world in a system that’s more open and decentralized than ever before. To do that, we need you to help us care for a little tiny piece of Miro.

If you’re not familiar with Miro, it’s “open Internet TV,” a player that can handle nearly any video file and it boasts more than 6,000 free Internet TV shows and podcasts. Miro handles Quicktime, AVI, MPEG, WMV and other formats with ease.

For a mere $4 per month, you can “adopt a line of source code,” to “keep Miro alive and growing.” That’s a steal for all the Internet video junkies who depend on Miro for their content fix.

Adopters will not only receive the warm fuzzy feeling of supporting their own bundle of code, they’ll get a customized page and widgets to display the code and a “photo” of your new little buddy. You have to hand it to the Miro folks. It’s a novel approach, and just might work.

April 29th, 2009

Oprah comes, Oprah goes: Who cares?

Posted by Joe Brockmeier @ 2:05 pm

Categories: Building Community

Tags: Oprah Winfrey, Advertising & Promotion, Marketing, Joe Brockmeier

As a tool, Twitter has its advantages and disadvantages, but does it really matter if Oprah Winfrey decides to keep up with her account or not? Apparently the Silicon Alley Insider finds it fascinating, even tracking the number of people following her and the rate of new followers compared to other popular folks on Twitter.

I don’t pay a lot of attention to entertainment news, but since Winfrey’s activity on Twitter is making the news I thought it’d be good to point out that this is a pretty poor metric for the success or failure of an online community. Whether Winfrey (or a ghost twitterer) is hitting Twitter to tell us all about her shopping sprees or lunches with other celebrities.

Likewise, how many followers a single person can attract is a pretty lousy metric for community health. Having Oprah on Twitter may have driven a lot of people to the service initially, but it’s whether they talk to one another — not Oprah — that matters.

April 18th, 2009

Prioritizing bugs to boost Linux adoption

Posted by Joe Brockmeier @ 6:30 am

Categories: Building Community, Developing Open Source

Tags: Bug, Linux, UNIX, Operating Systems, Open Source, Software, Joe Brockmeier

What are the problems that need to be solved to boost Linux adoption? And in what order? If we get the order right, we can make more users happier faster, says Scott Ritchie.

Ritchie starts by looking at bugs in Wine. After 16 years in development (give or take), Wine is pretty good, but it still can’t run all Windows applications perfectly. It runs some very well, and some not at all. But it’s not yet where users can simply run their Windows apps on Linux.

Ritchie looks at the bugs that Wine needs to solve before being able to run all Windows applications, and estimates about 10,000 bugs before it will be complete. That’s a lot of bugs, but not all bugs are equal. Some fixes will make more users happy than others:

Now let’s define an application as some subset of these bugs.  A working application is one that has all its bugs solved.  We can also give each bug a different relative probability of affecting an application - maybe bug x is 10 times more likely to affect an application than bug y.

A user is then defined as a set of applications he needs.  A “happy user” is one who has all his applications working.  Just like with the applications, we can assign relative probabilities to reflect the real world - World of Warcraft is 60 times more likely than CuteCatExploderPro.

After doing some thinking along those lines, and some scripting to model different scenarios, Ritchie comes to the conclusion: “The strategy we use - the order we tackle various bugs - really does matter.  Every strategy gets to the perfect 100% end after solving all the bugs, but some get you 10 times as many happy users when you’re only half done.  In practice, having far more users likely translates into extra developers and a much faster rate of development.”

The same thing is true of Linux: If you look at some of the barriers of entry for potential users, some are much higher than others. Driver support affects more users than other bugs or potential improvements. Now the question is, which barriers to knock down to make the most users happiest the fastest?

April 7th, 2009

Quality improves for Google Summer of Code

Posted by Joe Brockmeier @ 6:14 am

Categories: Building Community, Collaboration, Communication

Tags: Google Inc., Patches, Security, Joe Brockmeier

The Google Summer of Code student application period wrapped up last week, and the overall number of applications is down from 2008. However, this is shaping up to be a good thing.

Googler Leslie Hawthorn blogged about the numbers, and noted that the number of proposals (nearly 5,900) is actually down from last year, but the quality is up:

We expected some decrease this year, as we heard from many of our mentoring organizations that past experience had helped them refine their application process and that they’d instituted new requirements for applicants, such as submitting a patch. A quick survey of our mentoring organizations, with 96 out of 150 organizations responding, revealed that 60% of organizations who had participated in past instances of Google Summer of Code received higher quality applications this year, with only 3% responding that application quality had decreased. We’d also heard that the number of completely untargeted applications this year decreased dramatically.

The 2008 SoC drew more than 7,000 applications — so what happened this year? Better communication between mentoring organizations, stiffer requirements over 2008, and generally a stronger overall focus on quality over quantity. Many organizations even started to require a patch as part of the application process, which seems to have weeded out some of the “spam” applications.

Speaking for one of the mentoring organizations, the openSUSE Project had both: An increase in applications, and better applications overall. We had some great applications and projects in 2008, but the overall interest and participation seemed to pick up this year.

In part, I attribute this to better communication between the project and students. At least for openSUSE, I noticed an uptick in students seeking out mentors / potential mentors and discussing the applications with them.

And this is exactly what Summer of Code is really about: Getting students involved with FOSS projects and helping them be productive within those communities. Contrary to popular belief, Summer of Code isn’t just about producing useful code — the code that comes out of the program is a result of a successful collaboration between the student and project.

April 6th, 2009

Perfectionists need not apply

Posted by Joe Brockmeier @ 6:46 pm

Categories: Building Community

Tags: Repository, Joe Brockmeier

If you’re a perfectionist, or prefer to solve problems alone, you’re going to have some problems working with community projects. Individual contributors and companies need to get used to working in the open, and be willing to work towards perfection rather than trying to nail it the first time.

I was reminded of this after stumbling on this brilliant post by Drupal maintainer Angie Byron. Byron does a character study of two potential contributors, and their approach to submitting a patch to the project. The lesson? The perfectionist isn’t the most desirable contributor.

While Drupal itself is clearly an open, Bazaar-style project, many individuals in the Drupal community tend to take the perfectionist approach to development. After all, *thousands* of people will be using this code, and likely *hundreds* of developers carefully inspecting its inner-workings. How embarrassing would it be for another developer to stumble across a “no-brainer” bug in your code? Best to sit on things until you know it’s really solid before putting it out there in front of people. Right?

Sure, that sounds logical. But in my experience, people who take this approach to development in an open source community, and especially the Drupal community, are at a severe disadvantage to those who embrace the chaos and put their changes out in front of everyone as they’re going along, warts and all.

The lesson here is that the open source model is a collaborative effort. That doesn’t mean that a lot of communication will make up for really lousy code — but the people who succeed are usually those who are in the thick of it day in and day out, and who work well with other developers.

This is a hard lesson for developers with a proprietary background to overcome. For corporate-sponsored projects, the first impulse seems to be releasing code when it’s “ready” for a release. Then perhaps releasing features to a public code repository when the features are ready.

But really, the only way to do it right is to work in step with the community — meaning, making the public code repository the official repository, rather than doing work behind closed doors and then sending it out to the world.

April 2nd, 2009

How to make technology conferences suck less

Posted by Joe Brockmeier @ 6:44 pm

Categories: Building Community

Tags: Conference, Open Source, Productivity, Joe Brockmeier

There’s a dirty little secret to technology conferences: Most of them suck to some degree. It’s about time someone started thinking about how to make conference time more valuable and less stale, especially now that companies are cutting back on travel to shows.

I’ve been thinking about this quite a bit lately. We just announced the openSUSE Contributor’s Conference for this fall, and I’m on the presentation committee for OpenSource World and LinuxCon this year. After seeing Danese Cooper’s post about designing better conferences, I was finally moved to write about it. Cooper says:

Speaking personally, I’m much more interested in content and formats that are fresh.  As we’re reading these carefully worded abstracts, I keep thinking about how hard it is to even remember what my intention was when I get around to finally speaking 6 months after an abstract is accepted in traditional “Call For Papers” kinds of conferences…

Have to agree here: I’ve been submitting talks and judging talks for years now. It’s a chicken and egg problem — people plan their conference attendance far in advance, and choose based on the content at the conference. This means choosing talks well in advance, but by the time the talks are given… they’re usually a bit on the stale side.

And the traditional schedules packed with one talk after another, that may not be the best format for a lot of events, either.

So, what makes an ideal conference? There’s no single-purpose format that works for everybody — what works for the Open Source Business Conference attendees is going to have nearly zero value for the audience that attends FOSDEM.

Oddly enough, going pro doesn’t mean a conference will be better. Perhaps I’m a bit biased, but I’ve found that community organized conferences like SCALE, Ohio LinuxFest, Linux.conf.au, and so forth tend to be much more enjoyable and useful for attendees. In part, that’s because the shows are not organized with a profit motive in mind — and thus, they don’t cater as much to the sponsors. (Read: The speaking schedule is not “pay to play,” so the keynotes, talks, and format are chosen to benefit the attendee rather than the sponsors.)

A couple of suggestions for organizers to make the most of a conference:

• The audience comes first. Paid keynotes don’t give attendees value.
• Let speakers know what’s expected, give them guidance and suggestions on good presentations. Subject matter experts don’t always make good speakers.
• The “Barcamp” and “unconference” format works really well for “advanced” audiences. Bring Your Own Content is the format for the future.
• Panels can be fun, but no more than one panelist per 15 minutes of session time.
• Give the conference attendees a way to connect before, during, and after the event. Mailing lists, wikis, and other tools that let people reach out and connect and stay connected.
• Leave plenty of time for the “hallway track.”
• For the love of all that’s holy — give attendees plenty of electrical outlets and a robust network.
• If you’re starting a new conference, try to hold it somewhere other than San Francisco, OK? Done. To. Death.

I do hope that the Linux.conf.au, SCALE, LinuxFest NorthWest and/or Ohio LinuxFest organizers will sit down and write the “conference howto” for other organizers to follow. There’s a lot that goes into a good conference, and having to relearn those lessons seems like a real waste of wisdom.

March 20th, 2009

Apple still neglecting developer community

Posted by Joe Brockmeier @ 5:20 am

Categories: Building Community

Tags: Apple Inc., Developer Community, FreedomVoice Systems, Advertising & Promotion, Marketing, Joe Brockmeier

This week, Apple unveiled its iPhone 3.0 OS and wowed the world with new APIs and the addition of basic features that other mobile phones have had for years. But while the company is getting huge praise for its shiny phone OS, it still drops the ball when it comes to tending to its developer community. According to Wired, one vendor is in the hole $600,000 due to Apple’s neglect.

Eric Thomas, CEO of FreedomVoice Systems, told staff this week that the company is ceasing indefinitely any work on an iPhone voice app, called Newber, because Apple will neither accept it nor reject it. FreedomVoice has so far invested $600,000 and more than half a year in the app.

“We followed all guidelines set by Apple throughout the development process and have never received comment from Apple as to why the Newber application has still not even been reviewed,” Thomas wrote in a letter to FreedomVoice staff, provided to Wired.com. “Steve Jobs hailed the App Store as, ‘the best deal going to distribute applications to mobile platforms.’ Our experience is that it is the worst deal going.”

It’s bad enough that Apple stands as gatekeeper between developers and users, but to fail developers by keeping their apps in limbo for six months.

We should be surprised that Apple hasn’t gotten on the stick with its developer community. The iPhone is slick, to be sure, but it’s nothing without all the 3rd party apps that make it truly useful. And alternatives are starting to emerge.

Though none of the major contenders are truly “open” in every sense of the word, Android and others are much more open than Apple — and apparently understand the developer community a bit more. If Apple doesn’t get a clue, it may well see Android and others taking a bite.

It’d be nice to see Apple be more open here — coming from a FOSS background, I can’t identify with the concept of giving a single entity the right of deciding what applications may be shipped to users. But if you accept the idea that Apple should be a gatekeeper, the company could at least communicate with its developer community and give timely feedback.

March 17th, 2009

Vote early, vote often: Linux Foundation "We're Linux" voting begins

Posted by Joe Brockmeier @ 5:21 pm

Categories: Building Community

Tags: Video, Linux, Corporate Communications, UNIX, Operating Systems, Open Source, Software, Marketing, Joe Brockmeier

The Linux Foundation “We’re Linux” contest is entering its final stages. This weekend, the submission phase wrapped up and now it’s time for the larger community to do what it does best: Submit the work to as many eyeballs as possible to find the best entries.

Since I’m one of the contest judges, I won’t announce any of my favorites here. However, if you’re looking for suggestions, Steven J. Vaughan-Nichols picks seven of the best from the pack.

Head over to the Linux Foundation Video Site and click on the blue stars under the videos to rate them. (You’ll need to be logged into the Web site to be able to rate the videos.)

The top 10 rated videos will be selected next Wednesday for the “We’re Linux” judges to vote on. As mentioned when the contest started, the winner will win a trip to Japan for the Linux Foundation’s Linux Symposium in October 2009.

Real fun should start after the contest, when we see if the videos make any sort of dent in spreading the word about Linux. The video contest is a good start, but only a start. The Linux community needs to find as many ways as possible to achieve with marketing what it’s already figured out with code: How to turn a distributed contributor base into a machine for making things happen.

If all the video contest succeeds in doing is sending one lucky submitter to Tokyo, it won’t be much of a success. The challenge now is going to be how to get the winning videos in front of the larger audience that knows little to nothing about Linux?