If you haven't read Clay's piece on Situated Software, I can't really help you. Clay has, yet again, identified an important emerging trend of users as developers creating software for specific social situations. The amount of users as developers is clearly increasing, not just because the LAMP stack (Linux, Apache, MySQL, Perl) offers a low cost and accessible way to make stuff, but the rise of the hacker ethic. Clay has identified a trend that is not just a case of social Do It Yourself IT (DIYIT), but what I think is the beginning of a technology adoption lifecycle for social software. Situated Software arises when solutions don't match social needs. And right now there is a dearth of solutions. Most software begins as a rapid prototype, it iterates and if it has a market is then revised according to requirements side of the Web School. I'm seeing the rise of Situated Software in startups. Many of our favorite social software tools were first created for social situations personal for the innovator(s) and cast on to the Web. Necessity of success then makes them deal with scale. Startups, even the non-social ones, used to jump directly to the Web School. They would acquire three or more beta customers, generalize use and architect for presupposed success. But dearth of venture capital now has most software startups beginning as consulting firms or under the wing of a single large partner, so the first implementation is for the specific. So most enterprise startups begin with Situated Software for not just a specific process, but within a specific customer. Just as there is a chasm to cross in the market, there is a Development Chasm to cross in advancing the product. Actually, there are two: preparing the product to deal with the scale of the early majority and the customization requirements of the late majority. Thankfully, some software can continue to leverage the LAMP stack to deal with the former for architectual scale. I pointed out to Clay that while a wiki may meet generic requirements, use adapts for a specific social situation. Clay agreed and said this is what he calls Situational Information Architecture. He also pointed out that the social software for today's situations may spread to tomorrows not just by scaling through the lifecycle, but through the transmission of practices for others to adapt to their own situations. But it may just be too easy to point to where this is on the adoption lifecycle. I believe the increasing interdependence of networks and markets means the technology adoption lifecycle is changing.