Access to the site is only granted if contributors agree to a set of newly installed terms and conditions dictated by TWIKI.NET, a company founded by Peter Thoeny 12 months ago. His power to do so grows out of two sources: (a) he is the sole owner of the trademark on TWiki and (b) he is sponsoring the server hardware and thus had root access.

And now he has triggered the trademark gun and fired the TWiki community. He even repeatedly threatened people on the #twiki IRC channel that "[he has] been advised by one of [his] investors, Wilson Sonsini Goodrich and Rosati, that [they] need to protect [their] trademark". Clearly, their VC people have no picture of the situation other than their own return of investment. Sure, protecting a registered trademark is what it is all about. But threatening the community that has been working on TWiki on a volunteer basis for the recent 10 years that way is a bit strong. Too strong for the TWiki community.

If there was ever any hope to re-establish a relationship of trust and faith to create a win/win situation by combining community & commerce, this is totally gone now. Thoeny installed himself as BDFL (Benevolvent Dictator for Life) again, despite being rejected by a community vote during the TWiki Summit in Berlin last month.

During the TWiki Summit in Berlin 4+5 September 2008, it became clear that Thoeny has sold part of his trademark rights to his venture capital funded company. Part of that deal was that while he remains ownership on the trademark itself, TWIKI.NET gained the sole right to exploit the brand on a commercial basis. This created a completely new situation for the Open Source project and all of its already existing commercial eco-system. As a consequence, TWIKI.NET was asked to grant a perpetual license to the community to secure the legal situation for contributors and commercial stakeholders, a license that would only have formalized the way TWiki has been running for more than 10 years with Thoeny promising to "take care of the brand".

As faith in him as a leader diminished over the years, and the foreboding of a trademark problem increased, the community asked Thoeny to write down the rights he has granted orally before. Which he didn't. Instead he pulled the trademark trigger in a move he calls "relaunching the project" to "weed out" the good and the bad. Trust in Thoeny as a leader diminished last but not least when his role as a community leader became more and more mixed up with his interests as a CTO of TWIKI.NET, up to the point where he obviously showed more interest to cement a genuine marketing advantage for TWIKI.NET.

The rise of his newly created company continually eroded willingness to contribute to TWiki as an Open Source project. People were more and more irritated by the changed rules of the game. The community has been watching the actions of TWIKI.NET with a lot of interest, in the hope that they would add significant value to this very successful project. Unfortunately, they took an approach of recasting the success of the product, created with years of volunteer work, as their own success.

That's where Open Source shows its ugliest face. And there's definitely no beauty in this shock therapy, even though Tom Barton, CEO of TWIKI.NET says: "the beautiful thing about open source is you don't need to recognize the authority of TWiki.net". What an irony to close another very sad chapter. The last one for TWiki.org as we knew it before.

The appearance of TWIKI.NET on the scene forced a governance crisis TWiki was not able to overcome, despite the good progress that was made up to a couple of hours before. On the TWiki Summit in Berlin last month, a democratically elected Interim Board of Directors was founded whose sole agenda was to negotiate the conditions under which this governance crisis could have been overcome.

The plan was to create a TWiki Association consisting of a Board of Directors and a General Assembly following the example of KDE e.V. The board itself would have created so called Task Teams that manage the operational part of the project to a finer granularity.

The members of the Interim Board of Directors were in the process of creating the Articles of Association and were prepared for the next logical move in an ever growing project, organizing it similarly to other projects in the Open Source business. This formal body would also have been an entry path for sponsors and other organizations willing to partner with TWiki as a project. No such thing was available before. The only way outside parties could have made donations was to give them directly to Thoeny and thereby TWIKI.NET.

This was the case when Sun donated server hardware to power the TWiki.org community site. Sun sponsored TWiki as an Open Source project, not TWIKI.NET. However, there was no entity other than Thoeny and TWIKI.NET to handle these opportunities and resources. It now is clear that the access to these server resource has been used against the TWiki community itself by locking it out.

The democratically elected Interim Board of Directors of TWiki has been displaced by the trademark holder of TWiki as a final chord on the governance crisis. Now, Thoeny is sending around emails to high profile contributors individually to invite them to come back subordinate to the governance of TWIKI.NET. He obviously seems to be in hope that people will do so once the situation has settled. Quite far-fetched and not very likely to happen. Those same contributors who implemented the features he is praising aloud as the shiny new TWiki, are far too displeased by his hostile behavior to be willing to go back to business as usual.

TWIKI.NET is striving to repaint their move as a "new opportunity". What they don't see is that they have put their own business case into severe danger. They just lost the horse power for a product that they were selling. They have been signaling to the community that they don't have the manpower for certain developments and were seeking for help, even willing to pay work for hire. Another error. Adding money as an incentive to Open Source is changing the game completely. Before, people volunteered as part of an act of free speech. Add money to it and nobody will work for free anymore. This poisoned the dynamics.

The current situation is that all core developers have left the ship and joined a new undertaking with the working title NextWiki. This is a fork based on the current code in TWiki that will soon be released under a new name. The goals of NextWiki are clear. Basically, the plan is to found an Association as a formal body for the project, including the reorganization of its governance down to all operational questions, as was in progress for the TWiki project.

The result will be a much strengthened new player, much more agile as it just got rid of the reason for TWiki's ongoing paralysis.

There remains a message for TWiki's users: no worries, we continue working, faster and more productive than ever before, embedded in a volunteer-friendly environment. Sure, this fork now introduces a new choice that was not there before. Well, it was there before and it was introduced by TWIKI.NET, not those guys that "asked for a fork". TWiki users already had the choice between TWIKI.NET's product (a rebranded version of an old TWiki release, packaged as a VMware image), or Open Source TWiki, most recent stable version. This choice more or less remains available with the difference that you will get the real thing from a new site, reworked to be real Open Source, backed up by a large and highly motivated community as a guarantor for continuity and innovation.

There've been a lot of people that tried to integrate 4.2.0 into their LDAP infrastructure using one of the latest LdapContrib beta releases, and failed unfortunately. That's been a major headache for all of us and it turned out that 4.2.0 did a bad job refactoring its authentication and authorization code. While digging into the code we not only found it to be suboptimal in terms of performance and internal API, but also containing some sublte security bug when using non-alphabetic characters in a login name. That's been weeded out in 4.2.1 now. However, the latest LdapContrib betas will have to be rewritten once again to meet the changed internals of TWiki's user code. LdapContrib will continue to support TWiki-4.1.x, as well as TWiki-4.2.1 onwards, but not 4.2.0 as this simply was too buggy.

Anyway, a lot of people take a deep breath of relief that this patch release finally made its way out into the field and we are now able to concentrate on the next major release rolling your way with yet more exciting stuff under the hood.

Read on on what's new in this patch release, go get it here.

So right now, any non-gtk applications using flash, e.g. Konqueror, freeze solid on ``flashed'' websites. Firefox, being a native gtk application, is ok however ... waiting for Debian.

Last.fm is doing a great service! They've sent me an email notification that these videos are available on the base of my listening habits. All of the site is based on profiling their users, collecting data which song you played when etc. Maybe some day I will discover iTunes but it seems I am not ready for that hype.

And did you know last.fm has got a wiki too? Here's what they write about The Brand New Heavies. The Brand New Heavies are an acid jazz and alternative hip hop group formed in 1985 in Ealing, a suburb of London, England. Originally an instrumental rare groove group, the Brand New Heavies gained a cult following in the London club scene and soon signed to Cooltempo as acid house replaced rare groove in clubs. Lots of their content is carried over from WikiPedia. Let me guess, they don't sync their wikis if users write in one or the other places.

They f***ed all those people for nearly a decade that tried to cooperate with them to get Java running on different platforms than Windows. If you followed the history of Blackdown Java 2 you know how stingy Sun has always been to answer technical questions that these guys asked again and again without getting a sufficient answer. Blackdown tried hard to cooperate with Sun to bring Java to Linux but their stack was never a vital alternative to using the original distribution downloadable by Sun for free (as in free beer). And programmers that first of all want to get their own problems solved don't care as you simply risk to get fired for using non-standard tools if things go belly up due to incompatibilities between different Java engines. For a long long time there was a pressure to get a free Java implementation. Just count the lines of code other people where willing to write just to get around using Sun's Java. Good code, that will probably never flow back into an open sourced Java.

Yes, Java and all its APIs still runs best on Windows, Microsoft not being a particular friend of Sun and vice versa as you know. Nevertheless, Sun developed Java for Windows first as this is the biggest market. They always had to catch up with the underlying operating system and its moving APIs trying to lock out competitors. That surely was not cheap.

One of Java's key selling point has always been platform independence: ``write once -- run everywhere''. So far the theory but things are always different in real life. Trolltech had a nice twist on that meme rephrasing it ``with write once -- compile everywhere''. The differences between both approaches to platform independence are compelling. Java plain fails to run on multiple platforms for technical reasons or just because Sun did not deliver the equivalent software stack for other platforms than Windows; Java is slow as its byte code is still to be interpreted by a virtual engine even though you need a separate compile step. Qt, Trolltech's key product, on the other hand, is simply yet another library you link your programs against the result of which is a highly optimized executable. And you can do so on whatever platform you decide to support. Plus the code is more efficient. I could go on comparing Java's APIs with Qt for quite some time where Qt wins hands down, e.g. library design. But let's stop here.

In some respects Java on servers has to be judged differently than in browsers or on the desktop. Let me make it short: it is OK on servers but sucks everywhere else. Applets are dead. Swing sucks. It is too complicated. It looks bad. It is ugly, out of the box. It does not integrate with the rest of your desktop. If it does then it only integrates with a Windows desktop. Fonts are a nightmare. Themability and skinnability of its widgets is voodoo -- at least to me.

Next point: who is interested not only going to looking at the masses of source code but also understand and fix it? The anonymous Open Source masses? This project is much too large now to. It was locked away for too long. Things are fine if a community is given a chance to mature and grow as the software does it is grouped around. This is obviously not the case for Java. Just have a look at Open Office or Firefox. These projects have big big problems to get more coders involved, people that not only work around symptoms but understand and fix the underlying issues besides envision sensible enhancements. How many coders work on Firefox? Who is currently investigating buggy printing? How long does that bug persist? Is this issue being a key feature for browsers really 9 years, 7 months, 1 week, 6 days, 20 hours old with a long thread of comments circling around it. To be fair, we all have such bugs buried in you bug tracker too. But hey printing is so essential ... gosh.

One comment from a guy called Wells dating back to 2006-10-13 reads like this: While I wish I had the skills necessary to fix a bug like this I don't, but I have hung around now a year and a half to see what would happen and I find this bug an excellent case study in the Cathedral and Bazaar model of software development. It seems to defy traditional claims that the bazaar model is a superior development model when it comes to fixing top100 rated bugs. The wider community has not hunkered down and come up with a fix to this critical printing problem. Now the bug fix is slated for Firefox 3, if we should be so lucky. Keep up the good work! Not quite encouraging, eh? Don't forget that this browser has its own knotty history and this particular bug may be a good indicator of what the situation currently is for the Firefox project. As I trust in history I expect things to be even worse for Java. The community already moved on to different techniques. Will it come back to Java? Let's place a bet on ``no''.

Weird, isn't it. This reaction is really not helpful and may backfire soon. Is there truth in FUD? And btw Red Hat is not Linux in itself. But you knew that already.