• name
  When asked about about the name (which had confused us), humorously dodged the question multiple times. Not entirely sure why…
• reinventing the wheel
  Bespin makes heavy use of canvas, essentially reinventing the rendering of text and layout (using their Thunderhead toolkit).
  While contentious with regards to accessibility and web standards, this is necessary due to performance reasons.
  (Note: Not JavaScript is the bottleneck here, but the DOM is.)
• offline capability
  Currently Bespin should be considered a “hosted application”, requiring a server-side component.
  Personally, I don’t like the idea of relying on the “cloud” for my primary editor.
  While the Bespin team is planning to use Titanium eventually, Joe said it shouldn’t be too hard to integrate TiddlyWiki‘s file-saving code (similar to the XWiki integration), essentially creating a stand-alone HTML application.
• tools integration
  Since Bespin runs in the browser, it might be hard to integrate external tools (e.g. PyLint).
  I’m concerned that this might mean the respective server must support such applications, stripping away another bit of developer independence…
• active community
  There’s already an active community of hackers making use of and contributing to the project.
  (We’re also considering using Bespin as a front-end for TiddlyWeb.)
• Ubiquity as Firefox extension API
  On a slightly unrelated note, it has been suggested that Ubiquity might be integrated into Firefox, which in turn could lead to a pure-JavaScript API for extensions (currently writing Firefox extensions involves a lot of overhead, e.g. creating XML documents). That would of course be most welcome!

• XNA (Microsoft’s game development toolkit for Windows and Xbox 360) live demo was fun, and it seemed fairly easy to get started
• Python is suitable for game development (e.g. OpenGL with pyglet), though with obvious performance limitations
• Agile methodologies would be even more suitable in game development than in traditional IT, but apathy and lacking/flawed feedback loops (publishers and retailers are harmful intermediaries) seem to prevent widespread adoption^[1]
• Open Source is mostly shunned in game development, often due to apathy and ignorance (there are a few positive examples though, like Lua); extreme short-term thinking prevents the realization of FOSS’s long-term benefits; standardization is actively subverted by platform vendors^[2]
• my overall impression is that the gaming industry is pretty messed up, largely because it’s dominated by vendors rather than consumer interests

1. apparently, the gaming industry doesn’t perceive itself as part of the IT industry – while it sits somewhere between traditional IT and the movie/entertainment business, it tends to prefer the latter (which is also reflected in the semantics, e.g. “game studio”)
2. instead of licensing game engines (e.g. Epic Games’ Unreal Engine), why are there no collaborative development efforts – similar to the way Apache now provides a superior alternative to IIS

Our first idea was to use TiddlyWiki to aggregate data from various social networks, turning into a sort of global dashboard for users. However, the OpenSocial API does not permit this (yet, according to Google).
So we went for the opposite approach, embedding TiddlyWiki as an OpenSocial gadget. This opens up quite a number of interesting possibilities — for example, users composing and sharing notes.

The first step was to simply take the entire TiddlyWiki source code and wrap it into the required XML framework. Apart from having to deal with nested CDATA sections, this actually worked without too many problems (also thanks to the gracious help from a Google expert). We used TinyTiddly‘s externalized core to save us the headache of excessive scrolling through the source code. Since gadgets are limited to a certain display size, we decided to apply a theme designed for handheld devices^[1] (created by BT’s James Lelyveld).
The preliminary results can be seen here; the XML gadget file is located here.

The next steps, should we decide to follow up on this, are to integrate this with ccTiddly, as this prototype does not yet provide any way for saving the inputs. Also, there are some issues with running TiddlyWiki within a frame — for example, paramifiers and direct permalinks to specific tiddlers do not work properly.

While I’m not a huge fan of social networks (apart from Twitter, if that counts), this was a very interesting experience. Overall, the event was very enjoyable and well-organized, with quite a number of interesting attendees.

1. using Chef to build it from source

Some folks join the Peace Corps. Others join groups such as Habitat for Humanity. Still others choose to write open-source software.

Source: Josh at The Daily WTF (slightly modified)

Many people believe that the open-source principle equals grassroots democracy.
However, I don’t think that’s a fair assessment.

While community involvement is generally important and valuable, it is also a double-edged sword.
For certain issues, opening the debate to the community at large can prove an obstacle to making progress. That’s because discussions involving a large number of people can easily get out of hand — especially if there is no tangible concept yet to base the discussion on.
Also, many tasks require a certain expertise, and should thus be delegated to qualified contributors. The wisdom of crowds (as described by Surowiecki) is no panacea, but only applies to certain kinds of decisions.

That is not to say the community should be excluded though. The entire process needs to be transparent — not only to avoid alienating contributors and users, but also because diverse opinions and perspectives are essential to achieving optimal results (e.g. to avoid common traps like coders’ tunnel vision).
But this involvement should be timed carefully. Gathering feedback on a well-thought-out concept will often be more productive than starting a discussion without a solid foundation.

Bottom line: In my opinion, open-source projects are more about transparency and a diverse assortment of skills, rather than forcing everyone’s direct involvement on every single level.

Thanks to Saq and Phil for their insights on this topic.
I’d be happy to continue the discussion in the comments…