Daryl’s Flock Blog

We’re considering several approaches to publishing Flock extensions, and I want to get a feel for what the community thinks of the various approaches. There are two major considerations that pull in opposite directions:

1. Quality. In order to maintain a high-quality brand going forward, it might pay to limit what extensions we bless and associate with our brand. This approach guarantees for users that the extensions we feature are of high quality and provide a unified experience. The approach is exclusive, however, as many useful extensions might not pass muster from an experience perspective. For example, a neat extension produced by someone with limited UI experience or graphics resources might not make the cut. If we take this approach, it will be especially important that we work to provide resources that help developers produce high-quality extensions. If we limit what we feature, we should empower developers to stand a better chance of having their extensions make the cut. If we raise the bar by limiting what extensions we list, we raise the bar for extensions development, which ultimately benefits everybody.
2. Trust. Installing extensions from unknown sources can be dangerous, so it’s important to have an authoritative list of extensions that have been verified to work and not to be malicious. This approach serves the larger user base and supports extensions that are valuable despite a lack of UI polish (for example), but it does so at a potential cost to user experience and thus dilutes the experience we’re working toward providing within Flock.

This is kind of tricky to talk about, incidentally, as it’s definitely not our intention to denigrate the efforts of community developers. It’s just a reality that some developers are better developers than UI designers (and vice versa). We’re juggling here whether to try to enhance the overall experience of using Flock by listing only the best of the best extensions and whether to enhance the extensibility for a broader user base by listing everything under the sky that works with Flock.

It seems to me that there are several reasonable approaches:

1. Feature only the best of the best, period. The community can provide and vet other sites to list extensions, but Flock officially endorses only the best as chosen by the Flock crew.
2. List everything we know of and allow users to drill down and search for all extensions, but emphasize very heavily the best of the best as chosen by the Flock crew.
3. List everything we know of and allow users to drill down and search for all extensions, but emphasize very heavily the best of the best as chosen by the community through ratings, etc.
4. Blend approaches 2 and 3, allowing the community to bubble extensions up but also allowing the Flock crew to emphasize what we consider the best fits based on quality, branding, etc.
5. Just list everything, singling out at most things like recent and most downloaded.

There may be other reasonable approaches as well. This seems to cover most of the continuum, though. So, what do you think? Is raising the bar for extensions development worth possibly alienating some developers (my big concern)? Or is it more important to establish trust, making it easy for users to confidently install any extension that’s known to be safe and to work with Flock? I’d love to hear from both users and developers on this matter. I have a meeting on this stuff on Thursday.

technorati tags: flock, community, extend

We’re getting pretty close to being to a point at which we’ll be ready to accept developer contributions from the community. We still need to polish some of our documentation, and we need to make sure our patch review process is in place so that we don’t leave contributors hanging. In the mean time, we’d like to invite developers to join us in #flock-dev at irc.flock.com to get help with setting the build environment up. There are usually developers around who are happy to help, but on Wednesday and Thursday afternoons (PST), we’re going to make a special effort to keep an eye on the channel and lend a hand. If you’re brave, go ahead and dive in by reading the documentation on our wiki. If you’ve set up the Mozilla development environment before, the process is very similar and involves primarily getting a different source control management application (mercurial) and running a couple of commands to handle integrating our source with the Firefox base.

technorati tags: flock, community, dev