TWiki.net Kicks Out All TWiki Contributors 194
David Gerard noted an interesting story going down with a relatively minor project that has interesting implications for any Open Source project. He writes "Ten years ago, Peter Thoeny started the TWiki wiki engine. It attracted many contributors at twiki.org. About a year ago, Thoeny founded the startup twiki.net. On 27th October, twiki.net locked all the other contributors out of twiki.org in an event Thoeny called 'the twiki.org relaunch.' Here's the IRC meeting log. All the other core developers have now moved to a new project, NextWiki. Is it a sensible move for a venture capital firm that depends on a healthy Open Source community to lock it out?"
Re:Welcome to the new economy (Score:3, Informative)
Wrong logs (Score:5, Informative)
Re:Twiki blows (Score:5, Informative)
I think the most serious criticism of TWiki is its poor security track record. I used to run a site, until it was compromised by a widespread exploit uploading a PHP file as an attachment, which TWiki then saves in a directory served directly by Apache - so an attacker can upload any program he wants and it runs with privileges of the web server. In my case, it was a rather handy remote administration tool that lets you alter any file on the system (that's writable by Apache) and download the contents of /etc/passwd.
OK, anyone could get caught out by such a mistake, but the response of the TWiki developers does not inspire confidence. They added a blacklist of 'bad file extensions' so that filenames ending .php cannot be uploaded. Of course, this falls into the mistake of 'enumerating badness' and leaves you open to the next magic file extension that the developers hadn't thought of. At least in TWiki 2 the problem has been dealt with properly by using a CGI script to serve attachments, rather than leaving them to the vagaries of Apache's configuration (which is great for a website you maintain yourself, not so good for directories where anyone can upload any file with any name).
It appeared that the TWiki developers' security process was purely reactive - kludging in fixes to exploits as they were discovered - and nobody was auditing the code to discover holes before the bad guys do, or just to clean up bad smells that might or might not lead to an exploit later.
Looking at the TWiki code, it's rather a mess and doesn't seem to take the paranoid precautions you need in Perl when running system() and other interaction with the outside world - precautions particularly needed in a CGI program that's meant to be publicly accessible. I am a keen Perl programmer but TWiki is the kind of code that gives Perl a bad reputation.
That said, in an environment where you trust everybody (like a company webserver accessible only on your network) TWiki is a very handy application. I rather like the grungy way it keeps page content in RCS archives; you can hack up scripts to automatically import your existing static HTML pages into the wiki. But if I were installing a new wiki now I would use something else: preferably the kind of wiki that works by generating a set of static HTML pages and updating them on edits. That seems to have the smallest attack surface and the best performance.
New T&C's make no sense. (Score:2, Informative)
In the new T&C's for the "relaunched" Twiki it includes the following:
Derivative works
All GPLed content can of course be freely be redistributed and copied, as long as the TWiki trademark rights are maintained.
TWiki.org website content contributed by an individual is copyrighted by the contributing author. The collective work of the TWiki.org website is copyrighted by TWiki.org and may not be copied without written approval from the TWiki Community Council.
Are those 2 conditions even legal?
Poor decision... (Score:4, Informative)
Re:You make a good point... (Score:2, Informative)
In other words, you have no idea what you're talking about, but you feel free to come into a forum full of software professionals and make sweeping statements.
Yeah. Good luck with that career, young padawan.
Working on free software can also earn a paycheck. Big projects have funding.
Also, the vast majority of software developers work on bespoke, in-house projects, not things meant to be turned into COTS products. People pull in a free software package to get a job done for their company, and contributing patches back is usually to their benefit.
For example, I wanted to do some automated testing. I found that WebInject [webinject.org] did almost, but not quite, what I needed; I made the changes. All this was on the company's dime. With the boss's permission, I contributed the changes back; we benefit in that this new capability will be part of future releases, rather than requiring me to re-integrate.
We win, the community wins. And that's the day-to-day truth of free software: not people working for free in their basements, but skilled professionals sharing ideas to improve the craft of software.
Re:Twiki blows (Score:1, Informative)
That said, in an environment where you trust everybody (like a company webserver accessible only on your network)
I'm being nitpicky here but insider attacks are still a proper threat, in fact it's treated as one of the same level as others in some academic institutions that teach IT Security (at least the ones I've experienced, it's probably more if not all).
In a perfect world it's better to just remove the problem than to mitigate risk.
Re:What the hell? (Score:4, Informative)
Since Day One, Theony has been looking to cash in on TWiki. That's motivated a lot of dumb moves on his part — this last nonsense being one of many.
Actually, the big problem is not so much Theony's desire to be the next Red Hat as the boneheaded way he goes about it. He wants to sell TWiki as an "enterprise collaboration platform" despite the existence of many existing products in that customers space. Most of them are more powerful and easy to customize than TWiki, and many of them are open source.
The main result is that when you install a TWiki, your default pages are full of arcane markup designed to support these "Enterprise" features. When I installed my department TWiki, I spend a lot of time stripping out this crap, to avoid confusing my non-nerd users.
The current version also makes a new WYSIWYG editor the default — and hardwires it into the system in numerous places. Unfortunately, the editor is very buggy, with many formatting errors and frequent data loses. You can just disable the WYSIWYG plugin, but some of my users still prefer it. So I ended up enabling it and then carefully hacking the many places in TWiki where it assumes that you want the WYSIWYG editor, even if you say you don't.
Despite these clumsy attempts to support "Enterprises collaboration" TWiki has been notably deficient in the features an enterprise would look for, such as time zone support, use of a DBMS as a back end, a stable API, and a practical query language.
This last deficit was actually remedied in 4.2, which is one reason I upgraded. But the main reason was LDAP-over-SSL support, another enterprise feature TWiki only recently acquired — and which the company I work for requires me to have. Unfortunately, this version includes a major refactoring of the user authentication API. Not a bad thing in itself (and probably necessary for the LDAP thing), but it eliminated the object used to encapsulate user information! Not surprisingly, a bunch of plugins have been broken by this change.
If I ever have occasion to install another wiki, it won't be TWiki. I'll take the time to educate myself about one that still understands that wikis are about keeping things simple. That doesn't mean the software itself isn't complex, just that the complexity is hidden from the end users, and is structured in such a way that administrators and developers don't have to cope with a lot of spaghetti logic.
Re:Why not dispute his ownership of the trademark? (Score:2, Informative)
Trademarks don't work that way (Score:3, Informative)