Unless you are Twitter itself, that is. We wrote one month ago that Twitter's own staff list had hit the maximum number of members, 500. (It's not an unpopular list, either, almost 77K people are subscribed to it.) What would happen if Twitter hired more people, we asked? Would these limits be lifted for other users as well? Well, it turns out that the Twitter staff list is now at 545, another incredible growth of 10% in 30 days, and the list feature's limit appears not to apply in this case. Think these limits aren't important? Try making a list of employees at any large company, or of Women in Tech, or of People in Portland, Oregon.

A very small number of Twitter accounts has been allowed to create lists larger than 500 for some time, but we don't know anyone who has been allowed to create more than 20 lists in a single account. We've heard from a number of people on Twitter than this is a real annoyance, but the only person on Twitter's whole staff to have hit the limit himself was just testing the error message when doing so.

It's really nice to be able to read tweets from all the people who work at Twitter, or any other large group of people, in one place. Twitter, could the rest of us please use Lists like you're using them? With all the people on them that ought to be? (Twitter hasn't responded to our request for comment on their passing 500 list members yet.)

Below, a visualization showing Twitter HQ's embrace of its own powerful feature, Lists. Most people who work at Twitter follow at least one list, about half follow the official list and almost none of them make extensive use of list creation.

Thanks to data viz pro Michael J. Rubillo for creating the infographic above. For a more in-depth discussion of Twitter lists, their power and unappreciated potential, see our post Twitter's Staff is Growing Fast, But Has a Dangerous Shortage of Power Users (Infographics).

You can follow the list of ReadWriteWeb team members here.

Twitter's hundreds of millions of members include casual and professional users with a wide range of interests. There's no better way to dive deep into real-time discussion on a particular topic than by building or subscribing to a Twitter List made of people focused on a particular field.

This super-powerful feature of Twitter has been available for more than 18 months but remains severely limited and underdeveloped. Users aren't allowed to create more than 20 lists per account and each list is limited to 500 members. Those are just the limitations - there's a world of other possibilities that could be developed if Twitter HQ was really as excited about Lists as it ought to be. Unfortunately, as you can see from the infographic above, Twitter's hundreds of employees don't include any power users of Lists. Earlier this month Twitter's own List of staff members hit the 500 person limit, though! Might that be an impetus for the company to change things for everyone?

Three weeks ago we did some data extraction from the official Twitter List of employees to see how much the people who work there use lists. My conclusion: Twitter staff does use Lists, but not very much.

70% of the staff is subscribed to at least one list, but 30% isn't. Those who are average 3.6 list subscriptions each.

44% of the people on Twitter's staff haven't created any lists! Maybe if they all created a lot of lists they would agitate internally for the list curation interface to be better than the day it was when it launched.

I talk with people on Twitter who have hit their 20 List Per Account limit frequently and we're all frustrated by it. The workaround of course is just to create a new account. That's not an elegant solution, though.

How much sympathy are we likely to get from Twitter itself? Not much. One single person on staff has hit the limit of 20 lists per account. And he tells me he was just creating Lists titled one, two, three etc. while he was testing the error message that appears when you create the max!

Only 6 other people out of 440 on the list three weeks ago had created 15 or more lists.

Just 3 weeks ago there were only 440 people on the Twitter Team list, and now it's maxed out at 500. That's 15% growth over 3 weeks! Could Twitter be growing its team that fast? And if so, what are all these new people doing?

Two years ago this month the Twitter team had a mere 49 people on it - it's grown 10X in two years. At that time I wrote a blog post titled How Twitter's Staff Uses Twitter (And Why It Could Cause Problems), arguing that Twitter's own staff and its executive team in particular, didn't include any power users that could advocate for the development interests of power users at large.

Then CEO Evan Williams told me while I researched that article that "there are lots of different ways to use Twitter" and that he doesn't believe it's a good idea to follow more than 500 or 1000 people. Well, that's all well and good for him - but what about the thousands of people who advocate for Twitter's growth into all kinds of different business sectors and who use the service very differently? Ev today has created 3 Lists and follows 3 other Lists.

As the company has exploded in size, would it have been so hard to hire one or two people in the marketing department at least, if not in product development, who like to push the system to its limits in order to get from it what they can?

I emailed Twitter about these latest numbers we'd run and asked for comment, but the only thing I got was a reply that the analysis was "remarkable." Thanks, Twitter, but I don't really think it is remarkable. I think it's very logical, the kind of first level of analysis that a person would do upon seeing a huge teaming set of real-time, social, semi-structured and programmatically available data.

Come on, Twitter - could you please give us power users some more support? Two years ago Twitter's executive team didn't follow the creators of Twitter for iPhone (nee Tweetie) or Tweetdeck on mobile, but they did follow a bunch of celebrity bores. Then they ended up spending millions of dollars acquiring those two companies. Perhaps they should have been paying more attention to early adopter, power users of their own platform? Perhaps they should have a few on staff and give the rest of us some love? They say in technology that today's power users define tomorrow's standard use case...but the platform's evolution can't help but be hindered if those power users and their use cases aren't supported.

What will happen now that Twitter's own Team list is maxed out at 500 members? Hopefully limits will be lifted for all of us - and maybe just maybe someday the platform will be developed further in the kinds of directions that this powerful feature called Lists is pointing.

This year there has been a tremendous amount of buzz in Silicon Valley about curation. Magnify.net CEO Steven Rosenbaum recently published a book, Curation Nation that has sparked a tremendous amount of conversation on the topic. Likewise a post by Brian Solis has been retweeted thousands of times. My company, Pearltrees has just surpassed 100,000 curators and 10 million page views a month, and in the past two years nearly a dozen companies that incorporate digital curation into their models have launched.

With all the attention curation has suddenly received, people are probably wondering if this is just another fad or is it something bigger? Is curation something more important than just the flavor of the month. Is it something that's going to have real sticking power? In short, is curation something that really merits our attention?

First, curation is one of the underlying principles of the Web. This was recently discussed in an excellent post on Silicon Valley Watcher by Patrice Lamothe called "The Web's Third Frontier." When Tim Berners Lee originally conceived of the Internet, he envisioned three principal functions:

1. Allow anyone to access any type of document
2. Allow everyone to disseminate his or her own documents
3. Allow everyone to organize the entire collection of documents

Over the past 20 years what we've seen is the democratization of the first two principles above. Hypertext and Google made it possible for anyone to access any type of document. Platforms like WordPress, YouTube, Twitter and even Flickr have made it possible to disseminate documents. As Twitter co-founder Ev Williams said at last year's Web 2.0 Summit, one of his overarching goals was to democratize publishing "by lowering the bar about as far as it could go".

Secondly, we have very strong evidence that curation has begun a similar process towards democratization, and that what we are seeing now is an adoption curve similar to blogging. This has happened with Web 2.0 and it's why you now have to deal with friend requests from Grandma.

The graphic above illustrates this process of democratization. At the apex of the pyramid you tend to have people that use a technology as part of what they do for a living. With each successive shift in the user base a broader audience begins to adopt that technology until, at the bottom of the pyramid, the technology has permeated a society.

So what is the evidence that this is starting to happen? Along with the rapid growth of our community, the composition of our user base has shifted. At first it was people that curate as part of their daily work: researchers that are curating content for a project, journalists that are using our tools for their work. Now it's broader and more more representative of the early adopter crowd.

Here's what our typical user looks like today: most likely educated, professional, an archivist at heart, at some point may have been a blogger. They're "incidental altruists" - people that are happy to share what they've curated but aren't going out of their way to build value for a community. In other words, people that are mainly curating for themselves but are happy if what they've done benefits others.

These points all converge to give us a picture that we have crossed over from professional users to early adopters within the curation field.

Third, in recent months we have seen highly influential investors begin to focus on curation and also to make significant bets on the space. In fact, in a recent Huffington Post article on the topic, Steve Rosenbaum, the CEO of Magnify.net and one of the most outspoken proponents of the curation trend, quoted Russian mega-investor Yuri Milner as saying, "I think the next big theme is basically curation."

Similarly, Fred Wilson, has written about the value of curation in social services. His contention is that curation improves the signal-to-noise ratio in social Web services that have become "messy and hard to navigate." Yet another high-profile thinker and investor, Paul Kedrosky, contends that curation begat search which is being replaced once again by curation.

Clearly there are forces at play here - mainly curation gaining mindshare with investors, and their subsequent deployment of capital into the space - that are starting to provide the impetus for curation to truly take hold. Provided that these astute investors make their bets on the right entrepreneurs in this space, I believe it is likely that at least one of them will become the company Scoble suggests will result from capitalizing on the curation opportunity.

So is curation here to stay? I think it's safe to say it is. Curation is part of the DNA of the Web from its very origin, we have strong evidence that curation is at the beginning of the democratization process, and investors are providing the capital to ensure that this process continues. Given these facts I'm confident that curation is not just the flavor of the month, but a rapidly growing trend that represents both a third phase of the Internet and a huge opportunity for entrepreneurs and investors.

Photo by ilco

That's created a lot of opportunities for new sorts of digital storytelling, and one of the tools that the writers here at ReadWriteWeb have had in their toolbox is Storify. The website opens to public beta today.

When you're done, you have an easily embeddable story. You can also opt to notify the people whose tweets you've included.

Curation, Journalism, and Storify

With Storify opening to the public, we will undoubtedly see a whole new set of stories curated here. But during its beta, it was journalists who found the site to be particularly useful. NPR's Andy Carvin, for example, renowned for his curation of Twitter during the uprisings in the Middle East and North Africa, has storified several news events, including the assassination attempt on Representative Gabrielle Giffords.

Carvin told The New York Times that he realized that the reaction to the Gifford shooting was a story itself. "It quickly evolved into looking at how people were discussing the media coverage surrounding it and its potential political impact," he said. "There's a big need for tools that allow people to collect bits of social media context and organize them in some fashion."

With Storify launching its public beta today, it looks like people will have a new tool at their disposal to do just this.

See Andy Carvin and Emily Bell in The Revolution(s) Will Be Curated at the ReadWriteWeb 2WAY Summit, June 13-14 in New York City.

Despite all the recent hoopla about the Twitter ecosystem becoming unfriendly to third-party developers and startups, as Business Insider's Nicholas Carlson points out, Sulia may be just "the kind of partner Twitter doesn't want to kill."

That's because Sulia offers an important service built on top of Twitter that seems to be beneficial to all parties involved - users, publishers and Twitter.

The startup tackles one of the major challenges of Twitter: as its usage increases, it can be more and more difficult to find relevant and important content. Spammers have managed to infiltrate hashtags and keywords, for example, and it's not always easy, particularly for those who aren't experts in a particular topic, to locate those who are. If you're trying to search or follow an event or subject - say recent events in Egypt - then the "channels" that Sulia curates can be far more valuable.

Sulia's channels are built by analyzing the tens of millions of Twitter lists in order to identify the best-regarded sources. This is a real-time process and works across thousands of topics. Sulia then combines machine learning and human curation to help remove off-topic content. The result: "high-quality real-time Channels that are always on-topic, readable, and relevant."

Better Real-Time Content for Publishers

"Publishers want to include smart real-time content on their sites," says Sulia CEO Jonathan Glick. "The great thing about Sulia Channels is that partners not only get the best tweets from the best sources, but our customization services allow each partner to modify each Channel so that it reflects their unique editorial voice."

In other words, partners get to customize their channels by adding filters, featuring its own content contributors, adding or removing sources, and so on. Flipboard, for example, uses Sulia's news and event-based channels in its Weekly Picks section. Sulia works with publishers like Fliipboard in exchange for a fee, and some of this revenue goes back into Twitter's pockets.

It isn't simply that monetization route that makes this a good partnership deal. Curation is becoming increasingly important, and as Twitter builds out its own advertising and promoted Tweet efforts, it too may want to make sure it is targeting the right ads at the right people watching the right Twitter streams.

Without further ado, here's the scrapbook I created over my three day adventure. Admittedly my curatorial stamina began to wane a bit towards the end, but I pulled through! I'll continue to fine-tune this story over the next few weeks. If you have something you'd like me to add, please drop me a line on Twitter.

As far as we can see, these editors' decisions won't directly affect the content that appears on the front page, but their recommendations will surely influence the stories that the Digg community will vote for. After all, these modules are in a very prominent position on the most popular pages on Digg.

Votes, Algorithms and Editors: Taking the Hybrid Approach

This approach is similar to how the popular tech news aggregator Techmeme handles breaking news stories. While Techmeme's algorithms decide most of the content that appears on the site's front page, a group of editors also ensures that breaking news stories are posted to the site as quickly as possible. Asked about Digg's new approach, Techmeme's founder Gabe Rivera told us that he believes that "all bottom up approaches for surfacing news like voting and link analysis can benefit from curation from the top. Voters and linkers are critical, but they mainly care about the stories they're pushing or writing about, not the overall mission of the news aggregator, which isn't their job."

Will This Help Digg to Get Back on Its Feet?

The recent launch of Digg v4 quickly turned into a major disaster for the site, as as the new infrastructure turned out to be rather fragile and unhappy users decamped to other sites. Throughout this time, though, the Digg team continued to state that it wants to make the site a more interesting destination for mainstream users. By adding a more curated experience that can break stories faster, Digg could be on its way to achieving this goal.

How Will Digg's Users React?

On the other hand, though, Digg's power users are extremely sensitive when it comes to anything that looks like it could manipulate the site's democratic voting system and the editorial team now wields a lot of influence over which stories get popular and which sites get traffic from Digg. We will have to see how Digg's users react to this, but the first reactions from the site's users are actually quite positive.

As with the iTunes App Store, developers receive the standard 70/30 (developer/Apple) revenue split on app sales. Also like the iTunes App Store, Apple has created a long list of apps it plans to reject.

The list of apps Apple won't allow in its Mac App Store is long. Some of the reasons are relatively standard - for example, apps that cause damage to the device, utilize Apple trademarks, apps that don't work, etc. won't be allowed.

However, some of the Mac Store guidelines are less about consumer protection, and more about Apple's own version what it wants, as a company, to promote. Some call this "censorship," some call it "curation." Regardless of your position on the matter, it's clear the Mac App Store will abide by similar rules as the iTunes store. In fact, in reviewing the document, it looks like Apple cut-and-pasted quite a bit of the iTunes App Store Guidelines into the the new document.

Here are some standout, and perhaps questionable, examples of what Apple will reject from its Mac App Store:

1. Apps with "Easter Eggs:" Apps that include undocumented or hidden features inconsistent with the description of the app will be rejected.
2. No beta apps: Apps in "beta," "trial" or "test" versions will be rejected.
3. No duplicate apps: Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them.
4. No drinking/drugs: Apps that encourage excessive consumption of alcohol or illegal substances will be rejected.
5. No License Keys: Apps that require the entry of a license key will be rejected.
6. No Java?: Apps that use deprecated or optionally installed technologies (e.g. Java, Rosetta) will be rejected.
7. No auto-run: Apps that are set to auto-launch or have other code automatically run at startup or login without user consent will be rejected. Similarly, apps can't automatically add their icons to the dock or desktop.
8. No copying Apple!: Apps that look similar to Apple Products or apps bundled on the Mac, including the Finder, iChat, iTunes and Dashboard, will be rejected.
9. OS X may not be changed: Apps that change the native user interface elements or behaviors of Mac OS X will be rejected.
10. No rentals: Apps containing "rental" content and services that expire after a limited time will be rejected.
11. No RSS Readers?: Apps that are simply Web clippings, content aggregators, or a collection of links may be rejected.
12. No data collection: Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to information about how and where the data will be used.
13. No Chatroulette clones?: Apps that include games of Russian roulette will be rejected.
14. Define "objectionable:" Apps that present excessively objectionable or crude content will be rejected.
15. No porn: Of any kind. (Porn as it's defined by "Webster's Dictionary," that is).
16. No gambling: Of any kind.
17. No file-sharing: No P2P apps - apps that enable illegal file sharing will be rejected.
18. Religious apps must be for educational purposes only: Apps may contain or quote religious text provided the quotes or translations are accurate and not misleading. Commentary should be educational or informative rather than inflammatory.

You can read the entire list of guidelines here on pastie.org or by clicking through to the next page. 

App Store Review Guidelines
Introduction

The App Store has revolutionized the way mobile apps are developed and distributed. With over 300,000 apps and 7 billion downloads, it has been a huge hit with developers and users around the world. Now we are thrilled to be opening our new Mac App Store to the hundreds of thousands of Mac developers and tens of millions of Mac users around the world.

We hope the new Mac App Store is the most exciting place for users to discover and purchase their apps. To ensure that apps are reliable, perform as advertised, and free of offensive material, we will review every app on the Mac App Store based on a set of Mac App Store Review Guidelines that we are ready to share with you. These guidelines are designed to help you create and prepare your apps so they will sail through our approval process.

We want to help you reach tens of millions of Mac customers with your apps. As with the mobile App Store, developers will earn 70% of the revenues. Please join us as we launch our Mac App Store within the next 90 days, and together we can surprise and delight our joint customers.

Table of Contents

   Terms and conditions
   Functionality
    Metadata, ratings and rankings
    Location
    Trademarks and trade dress
    User interface
    Purchasing and currencies
    Scraping and aggregation
    Damage to device
    Personal attacks
    Violence
    Objectionable content
    Privacy
    Pornography
    Religion, culture, and ethnicity
    Contests, sweepstakes, lotteries, and raffles
    Charities and contributions
    Legal requirements

1. Terms and conditions

    1.1

    As a developer of applications for the Mac App Store you are bound by the terms of the Program License Agreement (PLA), Human Interface Guidelines (HIG), and any other licenses or contracts between you and Apple. The following rules and examples are intended to assist you in gaining acceptance for your app in the App Store, not to amend or remove provisions from any other agreement.

2. Functionality

    2.1

    Apps that crash will be rejected
    2.2

    Apps that exhibit bugs will be rejected
    2.3

    Apps that do not perform as advertised by the developer will be rejected
    2.4

    Apps that include undocumented or hidden features inconsistent with the description of the app will be rejected
    2.5

    Apps that use non-public APIs will be rejected
    2.6

    Apps that are "beta", "demo", "trial", or "test" versions will be rejected
    2.7

    Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
    2.8

    Apps that are not very useful or do not provide any lasting entertainment value may be rejected
    2.9

    Apps that are primarily marketing materials or advertisements will be rejected
    2.10

    Apps that are intended to provide trick or fake functionality that are not clearly marked as such will be rejected
    2.11

    Apps that encourage excessive consumption of alcohol or illegal substances, or encourage minors to consume alcohol or smoke cigarettes, will be rejected
    2.12

    Apps that provide incorrect diagnostic or other inaccurate device data will be rejected
    2.13

    Developers "spamming" the App Store with many versions of similar apps will be removed from the Mac Developer Program
    2.14

    Apps must be packaged and submitted using Apple's packaging technologies included in Xcode - no third party installers allowed
    2.15

    Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
    2.16

    Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
    2.17

    Apps that download other standalone apps will be rejected
    2.18

    Apps that install kexts will be rejected
    2.19

    Apps that require license keys or implement their own copy protection will be rejected
    2.20

    Apps that present a license screen at launch will be rejected
    2.21

    Apps may not use update mechanisms outside of the App Store
    2.22

    Apps must contain all language support in a single app bundle (single binary multiple language)
    2.23

    Apps that spawn processes that continue to run after a user has quit the app without user consent will be rejected
    2.24

    Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
    2.25

    Apps that do not run on the currently shipping OS will be rejected
    2.26

    Apps that are set to auto-launch or to have other code automatically run at startup or login without user consent will be rejected
    2.27

    Apps that request escalation to root privileges or use setuid attributes will be rejected
    2.28

    Apps that add their icons to the Dock or leave short cuts on the user desktop will be rejected
    2.29

    Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected
    2.30

    Apps that do not comply with the Mac OS X File System documentation will be rejected

3. Metadata (name, descriptions, ratings, rankings, etc)

    3.1

    Apps with metadata that mentions the name of any other computer platform will be rejected
    3.2

    Apps with placeholder text will be rejected
    3.3

    Apps with descriptions not relevant to the application content and functionality will be rejected
    3.4

    App names in iTunes Connect and as displayed on Mac OS X should be the same, so as not to cause confusion
    3.5

    All app icons should be similar, so as to not to cause confusion
    3.6

    Apps with app icons and screenshots that do not adhere to the 4+ age rating will be rejected
    3.7

    Apps with Category and Genre selections that are not appropriate for the app content will be rejected
    3.8

    Developers are responsible for assigning appropriate ratings to their apps. Inappropriate ratings may be changed by Apple
    3.9

    Developers are responsible for assigning appropriate keywords for their apps. Inappropriate keywords may be changed/deleted by Apple.
    3.10

    Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the Mac Developer Program

4. Location

    4.1

    Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
    4.2

    Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected
    4.3

    Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected

5. Trademarks and trade dress

    5.1

    Apps must comply with all terms and conditions explained in the Guidelines for using Apple Trademark and Copyrights and the Apple Trademark List
    5.2

    Apps that suggest or infer that Apple is a source or supplier of the app, or that Apple endorses any particular representation regarding quality or functionality will be rejected
    5.3

    Apps which appear confusingly similar to an existing Apple product or advertising theme will be rejected
    5.4

    Apps that misspell Apple product names in their app name (i.e., GPS for Imac, iTunz) will be rejected
    5.5

    Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request

6. User interface

    6.1

    Apps must comply with all terms and conditions explained in the Apple Macintosh Human Interface Guidelines
    6.2

    Apps that look similar to Apple Products or apps bundled on the Mac, including the Finder, iChat, iTunes, and Dashboard, will be rejected
    6.3

    Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple Macintosh Human Interface Guidelines will be rejected
    6.4

    Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected
    6.5

    Apps that change the native user interface elements or behaviors of Mac OS X will be rejected

7. Purchasing and currencies

    7.1

    Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected, except in cases where the application hosts plug-ins or extensions
    7.2

    Apps that create a store inside themselves for selling or distributing other software (i.e., an audio plug-in store in an audio app) will be rejected.
    7.3

    Apps that allow the user to purchase access to built-in capabilities provided by Mac OS X, such as an iSight camera, will be rejected
    7.4

    Apps containing "rental" content or services that expire after a limited time will be rejected
    7.5

    Insurance applications must be free and in legal-compliance in the regions distributed
    7.6

    In general, the more expensive your app, the more thoroughly we will review it

8. Scraping and aggregation

    8.1

    Applications that scrape any information from Apple sites (for example from apple.com, iTunes Store, App Store, iTunes Connect, Apple Developer Programs, etc) or create rankings using content from Apple sites and services will be rejected
    8.2

    Applications may use approved Apple RSS feeds such as the iTunes Store RSS feed
    8.3

    Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected

9. Damage to Products

    9.1

    Apps that encourage users to use an Apple product in a way that may cause damage to the device will be rejected
    9.2

    Apps that rapidly drain a products battery or generate excessive heat will be rejected

10. Personal attacks

    10.1

    Any app that is defamatory, offensive, mean-spirited, or likely to place the targeted individual or group in harms way will be rejected
    10.2

    Professional political satirists and humorists are exempt from the ban on offensive or mean-spirited commentary

11. Violence

    11.1

    Apps portraying realistic images of people or animals being killed or maimed, shot, stabbed, tortured or injured will be rejected
    11.2

    Apps that depict violence or abuse of children will be rejected
    11.3

    "Enemies" within the context of a game cannot solely target a specific race, culture, a real government or corporation, or any other real entity
    11.4

    Apps involving realistic depictions of weapons in such a way as to encourage illegal or reckless use of such weapons will be rejected
    11.5

    Apps that include games of Russian roulette will be rejected

12. Objectionable content

    12.1

    Apps that present excessively objectionable or crude content will be rejected
    12.2

    Apps that are primarily designed to upset or disgust users will be rejected

13. Privacy

    13.1

    Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to information about how and where the data will be used
    13.2

    Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
    13.3

    Apps that target minors for data collection will be rejected

14. Pornography

    14.1

    Apps containing pornographic material, defined by Webster's Dictionary as "explicit descriptions or displays of sexual organs or activities intended to stimulate erotic rather than aesthetic or emotional feelings", will be rejected
    14.2

    Apps that contain user generated content that is frequently pornographic (ex "Chat Roulette" apps) will be rejected

15. Religion, culture, and ethnicity

    15.1

    Apps containing references or commentary about a religious, cultural or ethnic group that are defamatory, offensive, mean-spirited or likely to expose the targeted group to harm or violence will be rejected
    15.2

    Apps may contain or quote religious text provided the quotes or translations are accurate and not misleading. Commentary should be educational or informative rather than inflammatory

16. Contests, sweepstakes, lotteries, and raffles

    16.1

    Sweepstakes and contests must be sponsored by the developer/company of the app
    16.2

    Official rules for sweepstakes and contests must be presented in the app and make it clear that Apple is not a sponsor or involved in the activity in any manner
    16.3

    It must be permissible by law for the developer to run a lottery app, and a lottery app must have all of the following characteristics: consideration, chance, and a prize
    16.4

    Apps that allow a user to directly purchase a lottery or raffle ticket in the app will be rejected

17. Charities and contributions

    17.1

    Apps that include the ability to make donations to recognized charitable organizations must be free
    17.2

    The collection of donations must be done via a web site in a web browser

18. Legal requirements

    18.1

    Apps must comply with all legal requirements in any location where they are made available to users. It is the developer's obligation to understand and conform to all local laws
    18.2

    Apps that contain false, fraudulent or misleading representations will be rejected
    18.3

    Apps that solicit, promote, or encourage criminal or clearly reckless behavior will be rejected
    18.4

    Apps that enable illegal file sharing will be rejected
    18.5

    Apps that are designed for use as illegal gambling aids will be rejected
    18.6

    Apps that enable anonymous or prank phone calls or SMS/MMS messaging will be rejected
    18.7

    Developers who create apps that surreptitiously attempt to discover user passwords or other private user data will be removed from the Mac Developer Program

Living document

This document represents our best efforts to share how we review apps submitted to the Mac App Store, and we hope it is a helpful guide as you develop and submit your apps. It is a living document that will evolve as we are presented with new apps and situations, and we'll update it periodically to reflect these changes.

Thank you for developing for Mac OS X. Even though this document is a formidable list of what not to do, please also keep in mind the much shorter list of what you must do. Above all else, join us in trying to surprise and delight users. Show them their world in innovative ways, and let them interact with it like never before. In our experience, users really respond to polish, both in functionality and user interface. Go the extra mile. Give them more than they expect. And take them places where they have never been before. We are ready to help.

In recent weeks, I've been experimenting with some newly released curation platforms. The first, Curated.by, lets you capture tweets around a specific topic using a plug-in that's installed on your Twitter.com profile. You can then easily tag and sort tweets into "bundles," which can then be embedded in a blog post for some additional context to whatever you're reporting on.

This week, I discovered startup Storify while watching the TechCrunch Disrupt conference. While Curated.by and Storify share the same core theme of curating social content, Storify goes beyond tweets by letting you insert content from YouTube, Flickr, Google search and more into "stories" which can be embedded into a Web page. I'm a sucker for experiments, so today I created something using Storify's platform. It all got kicked off with a single tweet.

From there, I took to Storify and began adding responses from the community. (Note to Storify: include Twitter mentions in addition to search in your next update).

Based on the responses, I added additional contextual information that included recent ReadWriteWeb articles and content from the various sources Storify supports. Here is the end result:

For a brand new service still in private beta, Storify is impressive. The ease of inserting tweets and additional content from across the Web was a generally pleasing experience. I did have some issues, though. After I had initially saved and embedded my story in this post, the tweets and contextual content I added randomly re-arranged. Considering the length of the story, it was a pain to have to go back and work on it for an additional 30 minutes. In terms of the presentation quality of the embed, it's good, but could use a little more beautification.

Storify lets you notify the Twitter users that were part of your story.

My biggest wish is that Storify make their stories "live." By that, I mean that I want anyone to be able to leave a comment on something that has been added to a story. For example, as you can see I replied to several of the tweets in the story using Storify's text module. But since there is no way for someone to reply to those, the conversation halts. I'm not sure if Storify wants their product to be that interactive, but it's something to consider, at least as an option.

I'm happy startups are starting to tackle curation. For a community manager, it's very nice to be able to capture what your audience is talking about and build an experience around it. It remains to be seen if Storify can make it as a standalone service, but I'd love to see their tools end up in a content management system like Movable Type and Wordpress.

What are your thoughts on Storify and emerging curation tools? Let us know in the comments!

Besides allowing users to create their own trails, they can also browse and search other users' trails. On its front page, Trailmeme highlights those collections that are especially popular among its users.

The company offers a toolbar for Firefox and a universal bookmarklet for creating trails, as well as plugins for WordPress and - in the near future - MediaWiki. Sadly, Trailmeme doesn't currently offer the ability to embed collections on other sites.

A New Kind of Publishing

As Rao told us, the main goal behind Trailmeme is to allow users to "navigate the web via well-curated trails," but given the projects connection to Xerox, it doesn't come as a surprise that there is also a publishing angle to this tool. Trailmeme offers users the ability to print trails and save them as PDF files. As Rao told us, in the long run, the team is also considering to offer publishers the option to monetize their efforts and sell printable version of their trails.

Will Users Care?

Overall, Trailmeme is an interesting tool (though it lacks the visual appeal of Pearltrees and browsing trails often feels a bit sluggish), but it remains to be seen how many users are actually interested in curating their bookmark to the extend that Trailmeme and similar tools expect them to do. For most users, Google has already replaced regular bookmarks to some extend. If done well, however, an expertly curated collection on Trailmeme or Pearltrees can provide a lot more value than a simple list of links on Google or Delicious.

Shortly after today's Google's event wrapped, I tossed up the following grapefruit:

Reactions ranged from disappointed...

To incredibly optimistic....

To downright paranoid...

For curating responses, we test drove Curated.by, which our own Marshall Kirkpatrick covered recently. It turned out to be a pretty quick and efficient way to capture what our followers were thinking. Even cooler, we're able to embed the rest of the reactions in this here blog post. Behold:

In addition to the Twitter, we also asked our Facebook community to give us their thoughts on Google Instant. Head over to our Facebook thread to see the responses and leave your own.

Do you have any fascinating insights on Google Instant? Please take the opportunity to leave them in the comments!

Until next time, Community Manager out.

It's quite simple: create a collection and drag Tweets into it, or use the service's new Chrome Extension to curate Tweets right from Twitter webpages. Then share your collections, embed them on a web page and subscribe to the collections of other users. Founder Bastian Lehmann, for example, curated a really good collection of Tweets about today's Apple event that I would have embedded below if the service had launched yet.

Curation is a beautiful thing and something that's still too hard to do online. Curated.by is likely to make a nice addition to any content curator's toolset. (See also Curated.info, a very cool blog subscription bundle sharing service.) The service still has some rough edges, and these sorts of tools tend to require more investment than most users are willing to make, but I'm personally very excited for it to finally launch. "Soon," Lehmann says.

Click to enlarge.

Last month the company announced that it raised $1.6 million in venture funding. I love what Pearltrees is trying to do, most people I talk to love the idea, and it's good to hear the service is getting so much traction. I'm waiting until the promised iPad version comes out before getting too excited about it.

It's hard to know what percentage of those thousands of links are pulled in automatically from synced Twitter accounts. Either way, traffic services report that thousands of people each day are visiting the Pearltrees site, probably between two and six thousand people in fact. That's not a lot, but it's better than a poke in the eye.

What do you think about Pearltrees? The unique interlocking trees-of-pearls interface sure is seductive. It's part brand-new and part old feeling - it harkens back to many geeks' fantasies of spinning links and sparkling orbs in their hands, like a contact-juggling, web-nerd, feed-reading version of the David Bowie character in Labyrinth. That's a pretty high bar to reach!

Have you found yourself using the service regularly, though? The people we see who have stuck with it have curated some awesome collections of reading material - see deep-thinking journalist and company advisor Tom Foremski's collections, for example.

The interface still just isn't quite there for me yet, though. I want to touch it, spin it and use it like a mindmap on my iPad.

At the recent Semantic Technology conference, I sat down with Evri CEO Will Hunsinger. He called Evri the "topical equivalent of a Facebook stream."

In a nutshell, Evri allows you to explore and track topics. Its homepage displays a current hot topic (at time of writing, it was Lance Armstrong and the Tour de France), with other trending topics offered in the menu (for example 'Gulf Oil Spill' is a featured trend and 'LeBron James' is listed as "Trending in US & World'). You may also enter your own topic into the search bar. Evri is like a mix between Google Trends and Google News, with liberal sprinklings of Twitter and Facebook.

Whither Twine...

Evri made the news earlier this year when it acquired failed semantic web bookmarking application, Twine. Curiously, Hunsinger described Evri as "the inverse of Twine" - because Evri does all the work, rather than the user. Twine is an application that relies on its users to actively bookmark pages, a la the much more successful Delicious. Evri automatically collates topical information and presents it the user.

Update: Twine founder Nova Spivack wrote in and stated: "Twine was in fact highly automated as well, but in a different way than Evri - Twine used NLP [Natural language processing] to auto-tag every entry, generate summaries, and used graph algorithms to make recommendations."

Where Evri shares similarities with Twine is in the ability for users to track a topic. Hunsinger said that Evri users may "follow a story as it evolves over time, and tune it." He described this as being like a "mini blog" for its users.

Twine appears to have been of most use to Evri for its underlying technology. Hunsinger told us that Evri is using technology it acquired from Twine to extend Evri's categories and for advanced filtering.

What's Next

Evri is not short on ideas and innovation - for example it announced a Sentiment API last August. However some of these ideas are slow to eventuate. Hunsinger said that the Sentiment API is not in commercial deployment yet, because it requires much more media in order to calculate sentiment and it tends to work best with well-known people (like Barack Obama). However, Evri is working on incorporating data about shares, tweets, and more in order to beef up its Sentiment analysis engine.

The company is also currently working on what Hunsinger described as "Pandora-like recommendations," referring to the geographically-limited online music service Pandora.

Other expansion plans include launching one new channel per week, to extend Evri's topical coverage.

Can Evri Compete as a Consumer App?

Evri is an interesting product and is currently being used by media partners like Hearst and Canwest.

However, Evri will likely continue to struggle as a consumer offering. It's competing against a plethora of real-time news apps - everything from TweetDeck, Google News, Topix, Techmeme, and more. I wouldn't be surprised if Evri is eventually acquired by a big media company for its technology, much as Evri snapped up the struggling Twine for the same reason.

If the previous era of innovation on the Web was fundamentally characterized by the democratization of publishing and content creation, the next era may be based on finding solutions for building value on top of all that newly published data. Much of that value capture will be performed by machines, but tools for humans could be a game changer as well.

The gap between the value that's made possible by all this data, and the power of the tools available to consumers to capture it, is so great that it simply must be filled. Each progressively simpler, faster and more powerful tool for everyday people to build and share collections of content is part of the race to capture that market.

The addition of easy curation, if primarily in-network for now, to the giant WordPress community is a big advance for the popularization of curation.

Can Curation Catch On?

Will curation truly become a substantial market, capable of sustaining itself? Previous developments in the democratization of publishing have had mixed results. Blogging, photo sharing and video distribution have taken off. Mapping and podcasting, arguably, haven't caught on as widely or sustainably.

Maybe the old 1/10/90 rule will pay off when it comes to curation. One percent of people create content, 10% share it and 90% primarily consume it. If you believe those numbers, maybe the curation market has 10 times as much opportunity as the previous market for publishing tools.

What do you think? Do you agree with this assessment of the opportunities in content curation? If you disagree, please say something and stop me before I say all of this again next time a curation feature is launched somewhere big.