This thought has been floating around my head for quite some time now and I finally bit the bullet and released it from the draft state it had been sitting in for too long: there are quite many similarities between
Open Source Software (OSS) projects and most of today's popular
Web 2.0 sites, but there is also one odd difference that I wonder about.
For both worlds, the concept of collaboration, participation and giving more power to their users is a key component. OSS projects need contributors for patches and bug reports, but also for feedback, translations, artwork, advocacy in order to be popular and healthy. The project's developers need to be open for suggestions, listening to their user base on where the project should be heading. They also usually strive for open standards and APIs, allowing easy combination and interaction with other Open Source Software so that other projects can build their work on top of theirs or compliment it. A successful OSS application gains popularity by the snowball effect: users of the product find it useful and recommend it to other users seeking for similar functionality. These too start to contribute to the project in various ways, making it in turn more useful and attractive for even more users and so on.
The same is true for Web 2.0 sites: they depend on a user base that creates and provides content that makes their site useful and popular, e.g. blog postings, pictures, articles and other content, but also by providing feedback and bug reports about the site itself and recommending it to others. A successful Web2.0 site needs to be as open to user feedback as a regular OSS project in order to remain attractive and maintain a loyal user base. So it's a lot about participation and empowering the users to contribute and control the content - the part that actually makes a site useful and attractive. Many of these Web2.0 sites also provide public APIs (e.g. SOAP, REST, XML-RPC or RSS, just to name a few acronyms) that allow others to access their services and functionality and reuse or combine them with their own work. And by using technologies like AJAX, most of these sites actually look and feel like regular desktop applications already.
But there is a strikingly difference: even while most Web2.0 sites are based on Open Source technology (e.g. the LAMP stack or Ruby on Rails), only very few ones actually carry on the OSS philosophy and make their own code available as Open Source as well. Not that they would have to do so, as there is this so-called ASP loophole in the GPL and most other OSS licenses: web sites are not actually distributing their application code, so they are not required to disclose the source of their applications.
But why do they break the chain here? One could argue that the obvious reason for that is that most web sites are created and maintained by companies, that are doing this for business reasons and want to maintain their competitive edge over others. However, many sites started as a hobby project by an individual or a small group and were converted into commercial entitities once they became successful. Even in these early stages it's rare that sites provide their source code. But isn't Web2.0 mostly about the users and content and not so much about the technology behind it? Would it really make a difference if the source code of a site is freely available?
In the OSS world, users could just fork off a project, if they don't feel the project is going the right direction or it has been abandoned by the original author. This sometimes leads to much better applications than what the original project came up with. This also leads to a healthy competition and to much better software with less duplication of work in the long run. And this is being recognized by more and more software companies as well - there is a large and growing number of OSS applications that are not maintained by a group of volunteers, but by a commercial entity.
In the Web2.0 world, people start creating new sites from scratch again and again, resulting in a vast amount of sites that serve a similar purpose, all with their own warts and deficiencies, splitting up the user base and available content. This causes fragmentation and makes it much harder to create one useful resource. And they are all on their own in maintaining and improving their sites, to fulfill the requests of their user base and keeping them happy and loyal.
I wonder if and when Web2.0 developers will embrace and extend the concept of sharing their code as well, to let others help them to become even more powerful and popular. Once a site has gained a certain popularity, there is plenty of new features that their users will ask for, or bugs and deficiencies that are in need of fixing. Making the source code available would allow others to jump in here, opening yet another channel of possible contributions and community-building. The Open Source community provides numerous lessons to learn from. True, others may then be able to take the code and create a site that provides the same services and experience. But they still would have to gain traction by creating a community and content before they would become a serious competition.
One great example of how this could be done is Wikipedia - they maintain Mediawiki (the application that powers their site) as a regular OSS project, which has made it one of the most popular and powerful Wiki applications around and has allowed others to create Wiki sites about all kinds of topics on their own.
And while it's not really true Web2.0 company, I also welcome Linden Lab's decision to open up the Second Life client source code. I am confident that the experiences they make with this will encourage them to consider opening the sources of the server code as well at some point...
But they both have grasped that it's not so much about the technology and software, but much more about the users and the content created by the community that makes them popular and successful. This is something one can't simply take and create a competing offering, even though the source code is available.
The slides are now available from the session page linked above or from the 
