This is what I think:

• Community:
  • Trust the members’ input.
  • Allow the members to be known and get credit by measuring their contributions.
  • Allow other members in the community to measure and respond to contributions.
  • Enable members’ knowledge base to evolve as processes and concepts change.
  • Enables user to embrace the content ownership
• Content
  • Make it easy to contribute to your knowledge base and make it accessible to others.
  • Reviews, Ratings, Comments, Focus: Freedom of expression
  • Free content
  • Using the power of the crowd
  • Originality
  • Community decides what they want to see on the site
• Context
  • Displaying the information based on reality of the user or page
  • Giving the value to people near you (in taste or physical location)
  • Provides personalization of the content
• - Commerce
  • Adapting non-revenue-generating website into that generates revenue
  • Via affiliates programs
  • Without disturbing the community
  • Should be well hidden between the lines
  • $$$
• Personalization
  • Allowing the user to tailor the site in accordance with their tastes and preferences.
  • Caters the sense of ownership / ease of use
• Vertical Search
  • Introducing the context into search (showing results that are more relevant to user)
  • Introducing other sites (possibly affiliate sites/competitors) into search.

Here is the related US code:

§ 2252C. Misleading words or digital images on the Internet
(a) IN GENERAL.—Whoever knowingly embeds words or digital images into the source code of a website with the intent to deceive a person into viewing material constituting obscenity shall be fined under this title and imprisoned for not more than 10 years.

(b) MINORS.—Whoever knowingly embeds words or digital images into the source code of a website with the intent to deceive
a minor into viewing material harmful to minors on the Internet shall be fined under this title and imprisoned for not more than 20 years.

(c) CONSTRUCTION.—For the purposes of this section, a word or digital image that clearly indicates the sexual content of the
site, such as ‘sex’ or ‘porn’, is not misleading.

(d) DEFINITIONS.—As used in this section—HR 4472 EAS.

(1) the terms ‘material that is harmful to minors’ and ‘sex’ have the meaning given such terms in section 2252B; and ‘‘(2)the term ’source code’ means the combination of text and other characters comprising the content, both viewable and nonviewable, of a web page, including any website publishing language, programming language, protocol or functional content, as well as any successor languages or protocols.’’.

(b) TABLE OF SECTIONS.—The table of sections for chapter 110 of title 18, United States Code, is amended by inserting after
the item relating to section 2252B the following: 2252C. Misleading words or digital images on the Internet.’’.

hehehe. Next time you post the goatse man or the bath tub girl, remember this…

Linus Torvalds – The Linux kernel author
Dave Thomas – Author of the Pragmmatic Programmer, Programming Ruby and other great books about programming. One can read his mainly programming-related thoughts here.
David Heinemeier Hansson – Author of the Rails Framework – the new hot web development framework. He has a weblog here.
Steve Yegge – Proably the least known from guys here, but also made one of the most interestings answers, has a popular weblog about programming. He is also the author of a game called „Wyvern”.
Peter Norvig – Research Director at Google, a well known Lisper, author of famous (in some circles at least) books about AI. See his homepage.
Guido Van Rossum – The Python language creator
James Gosling – The Java language creator
Tim Bray – One of the XML and Atom specifications author and a blogger too.

Read the rest of the interview from here: StiffLog

These are the things to look out for when building a large application on web. Most of them I agree, some of them I don’t. This list also should keep in mind that, real world problems are not that perfect. I marked the ones that I strongly agree with an asterix (*).
I also filtered out the things are specific to del.icio.us from the original text.

• Browser quirks. CSS/JavaScript/rendering. IE caching.
• Scaling: avoid early optimization. SQL doesn’t map well to these problems – think about how to split up data over multiple machines. Understand indexing strategies, profile every SQL statement. Nagios or similar for monitoring.
• Tags don’t map well to SQL. Sometimes you can prune based on usage – only index the first few pages for example. This keeps indexes small and fast.
• *Some latency in the system is OK – work out where you have leeway, e.g. RSS feeds can fall a few minutes behind without anyone minding.
• *People are always going to abuse your system (scraping, greasemonkey, etc.)
• *“Idiots are a lot smarter than you” – wait to see what breaks before you fix it.
• *Learn Apache – tuning can make things a lot faster. Understand headers, mod_rewrite (a dark art). Put a proxy in front of Apache e.g. Perlbal from LiveJournal – one guy on a modem can suck up lots of resources otherwise.
• Images off a different server, RSS from a different server.
• “Save site for offline use” feature in IE is particularly nasty.
• *The easier the API to get in and out of, the more people will use it. There’s a long tail of smart developers. Stuff like SOAP discourages adoption. No API key = people can play with it faster; drives attention.
• Dont expose your unique id’s to the outside world (php?id=1 etc.) people can scrape through everything very easily. This is why del.icio.us uses MD5 hashes of links instead.
• Giving everything a unique ID in the database is a scaling problem in its own right.
• *Features: the features you put in are as important as the ones you leave out. There’s no “send a note” in del.icio.us feature because e-mail already exists.
• I don’t add featues that are available elsewhere e.g. messaging
• *When people ask for features, get to the bottom of why they are asking for that exact thing. Solve the problem, rather than doing exactly what your asked for.
• With tags, people ask for “A and B and NOT C or D” – but less than 1% of queries even use more than a single tag.
• *RSS important in del.icio.us, because it’s a native way for people to access lists (of links). Put RSS everywhere you can. del.icio.us does way more RSS traffic than HTML or API stuff – partly because of poorly written readers. Understand the headers – especially if-not-modified.
• *Make sure the URLs follow the path of the site. DONT include session data, drop ugly details that are to do with the system, not the user (.php, .aspx, ?, &, etc.)
• URLs are prime real estate – respect them (Good URL structure writeup from another carson speaker – http://www.plasticbag.org/archives/2003/06/on_permalinks_and_paradigms.shtml )
• *When you chose what to build, solve a problem you have yourself so you can be sure to understand it. Passion counts. It’s cheap and easy to build stuff, so other people will be building it too.
• *A niche product with a limited audience is still good business (with how advertising and paypal work)
• *Every day that you don’t have something properly out in the world (not on an invite only beta) you’re losing a chance to gain users. Get it out there ASAP.
• Aggregation is often a focus of attention (latest, most active, etc.)
• *As the population gets larger, the bias drifts; del.icio.us/popular becomes less interesting to the original community members. Work out ways to let the system fragment in to different areas of attention.
• “Spam is attention theft” – that’s one of the reasons del.icio.us doesn’t have a top 10 links of all time – it’s an attractive nuisance.
• *When you’ve figured out someone is spamming, don’t let them know – let them keep posting and just silently junk their stuff.
• *Make users do the minimum amount of work. But make them do something.
• Understand the user’s motivation: “You have to understand the selfish user” – user #1 has to find the system useful or you won’t get user #2. Systems that only become useful when lots of people are using them usually fail, because there’s no incentive for people to contribute themselves. The real trick is to make the user base you have want to invite more people in to the system.
• *Manage your effort – be careful where you spend your efforts.
• *Don’t waste time building features nobody uses.
• *Measurement: watch your system intensely: “Intuition is ideas backed by numbers”
• *Measure behavior rather than claims. del.icio.us doesn’t have stars because why would you bookmark something that was no good? This way people bookmark things that they really care about rather than trying to tell the system things.
• *User Acceptance Testing (UAT) is important. Make the system suitable for the people actually using the system. Everybody on the team should see this in action. Labs are great but expensive. If you don’t have a lab do ghetto testing in Starbucks. We did one day then two days user testing in a user testing lab.
• *Goals skew the results. People don’t read, they cram crap in to boxes. Let people wander don’t give them tasks.
• *You have to speak the user’s language. “Bookmarks” are what you call them if you use Netscape of Firefox – most users these days know the term “favourite” instead. Half of his population (? users) didn’t know what a bookmark was.
• *Don’t make users register before they can get in to your site. Maybe even give them an anonymous account to play with. A lot of users want to know what they’ll get if they register – especially from fear of giving out email address, spyware etc. You can’t tell them; they’re not going to read it. You have to show them.
• *Use Verbs – doing words – to prompt actions.
• *If users do have to register, send them straight back to where they were when they’re done. Don’t dump them on the homepage.
• *“Design Grammar” – if you’re presenting a system that’s different from how other things work (del.icio.us had novel tags, save your bookmarks to the web) you should still try to reflect the design patterns of the web.
• *Morals: You have to develop a sense of morals when you build your system. It’s the user’s data; it’s not yours. Make sure they can remove themselves and their account if they want to.
• *Infection: Understand infection vectors for promoting your system. “Enable evangelism”. RSS lets you get at users who don’t use your system directly. Also think about iCal, M3U – anything that a desktop app can consume over HTTP. Do an inventory to get into every desktop app. possible.

• That won’t scale.
• That’s been proven to be O(N^2) and we need a solution that’s O(NlogN).
• There are, of course, various export limitations on that technology.
• If we go with that idea, we’re going to have Don Marti camped out in the front lobby with 300 angry software jihad supporters. (this gave me a good laugh)
• No, that would break object encapsulation.
• I don’t think that’s altogether clear. Please write it up in UML for me.

more here

10.Fix only the bugs that annoy your CEO.
9. Fix every bug (never ship).
8. Don’t fix any bugs (ship today!).
7. Fix only the bugs that annoy your CEO’s spouse/daughter/pet hamster.
6. Require approval for every decision from the most annoying and least intelligent person in your organization (possibly redundant with No. 10).
5. Start on a bug at random, and when you’re halfway finished, switch to another. Repeat.
4. Play bug hot potato. Don’t fix bugs, just keep assigning yours to someone else.
3. Put bugs in alphabetical order and fix them from A to Z, skipping vowels. (Hint: if you relabel bugs appropriately, this is equivalent to No. 8.)
2.Create a complex parliamentary system of delegates elected by two-thirds majority to draft a charter of bylaws and rules of order for the formation of three bilateral subcommittees empowered to moderate future strategic defect management discourse.
1.Spend all available time debating whether your current process appears on this list.

a nice article is available on OnLamp.