TWiki.net Kicks Out All TWiki Contributors

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?"

Comments

Answer:

[ustolemyname]

No.

Server logs reveal real reason for lockout

[Anonymous Coward]

bidi-bidi-bidi bidi-bidi-bidi bidi-bidi-bidi...

You make a good point...

[Anonymous Coward]

but on the other hand, yes.

Re:You make a good point...

[Ethanol-fueled]

Close_Source==Money, Open_Source==!Money

Fixed it for you. I'm a noob taking a software engineering class at a community college.

We had a consultant come in for show-and-tell and he made some very good points, but he told us to stay away from open source because(shortened version) if we wanted to be well-known in the open source world then we'd have to slog it out full-time, fighting amongst other egos working for free just trying to get our names known.

But how is that different from working on proprietary software? Working on proprietary software earns a paycheck.

Note that the above is not my personal opinion, but after I graduate I won't have any more basements to live in and I will be hungry.

Re:You make a good point...

[electrofelix]

The majority of the big open source projects are developed in collaboration by companies paying their employees to work on them in order to get more out of the software in their environment. So it suggests that the consultant in question may not be the best person to listen too

If you plan to try and make a name for yourself in the hope of getting spotted and hired, that's probably a tall order. The rest of us just look for a job that will result in us getting paid to work on open source.

Of course it also ignores the other benefits to a developer: Gain experience with a particular language, sharpen your coding, prove that you're coding is good enough to be accepted by a project, become familiar with various API's.

Being able to demonstrate in an interview that you are familiar with the API's, language, coding style, algorithms that are in use in the job that you are applying for should prove invaluable. Too many proprietary companies have a habit of strapping you down with so many NDA's that it's virtually impossible to discuss what you're doing in your current job aside from vague details.

Re:You make a good point...

[Foofoobar]

Well I don't know of any open source developers who are hungry or live in basements. In fact they are VERY well paid; they work on their open source projects as part of their job (sponsored by their employer) or in their spare time (hobby,cash on the side). As for not making money, it's only when you look at it from a TRADITIONAL model. Every developer can make money if they want once they become a contributor to a project. They can write a book on the project, they can expend the project, they can start a support company for the project, they can do training or installing of the project, etc etc.

This is why we don't live in basements and are successful. We see more than one answer and more than one way to make money. Tfrue entrepeneurs realize this and don't just sit on their ass and whine about open source tealing their glory; they realize that open source is the new market and adapt to the changing market.

Perhaps you will realize this when you come out of your parents basement.

Re:You make a good point...

[Anonymous Coward]

I will let you in on a little secret. I went to a division III college in a small town. The people I ended up graduating with in computing mostly had trouble finding jobs and those that did seemed bored by them, mostly working in insurance, accounting, etc. They were taught VB, Java, and Cobol in school, but not necessarily how to think like a programmer.

I ended up going back to school at a much larger school, and getting a degree in an analytical field, which has a piece of open source software that I use at my job regularly. I have contributed my time and efforts to improving this project because I use it and need those improvements, and it helps others. I do this during work sometimes, but often times at night. I do this because I *like* it. I have no conceptions of making a name for myself.

And now I've just switched cities and had to find a new job. It's tough for a lot of people. Guess what? During the interviews, it comes up that I actually enjoy programming, contribute to this project, and generally have a good understanding of programming. I've had three offers this month already, in a tough economy.

The point? It's much easier to find work when you are passionate about what you're doing, as many open source authors are. It's not cause and effect, it's correlation. Those who are working on open source tend to be those who really enjoy programming, and that is of course correlated with being good at it. I would not listen to anyone who told me to 'stay away' from it if I enjoyed it, that sounds like a pathetic person.

Re:You make a good point...

[eugene_roux]

...PHP experience is of curse...

Yep.

Sounds about right to me...

Re:You make a good point...

[Angostura]

Remember folks, never have any hobbies, never do voluntary work, don't sit and stare and a sunset. The pay for any of those is dreadful.

Twiki blows

[SuperBanana]

...at least, the version we used did. Sample problems, just off the top of my head were incompatibilities with Safari, and moronic account "management".

Despite clear evidence that Safari does auth just fine, Twiki wouldn't let any of our Safari users view pages without presenting them with TWO auth requests, and the developers blamed Apple and refused to release a fix into code.

A "reset my password" form would (are you ready?) email the wiki maintainer with a request to reset that user's password.

While it's fast and has a simple file-based structure, it's also one of the worst web apps I've ever seen.

Re:Twiki blows

[Ed Avis]

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.

Re:Twiki blows

[Omnifarious]

It looks like then that they're well on their way to becoming a respected piece of enterprise software.

Re:Personal crap.

[larry bagina]

so she's available?

Re:Welcome to the new economy

[zaliv]

A clarification: TWiki has never received any funding, let alone by a venture capitalist. This has been a takeover out of the blue.

Wrong logs

[nuddlegg]

The logs in the posting above are not so interesting. If you need the logs of the way this was communicated to the TWiki community then have a look at http://twikifork.org/pub/Fork/TWikiReleaseMeeting2008x10x27/twiki_release_2008_10_27.log

Re:Wrong logs

[u38cg]

Sorry, last post ate the nicks. Try again:

--- Log opened Mon Oct 27 17:55:35 2008
17:55 -!- gmc [n=gmc@freenode/sponsor/gmc] has joined #twiki_release
17:55 -!- Irssi: #twiki_release: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
17:55 -!- Irssi: Join to #twiki_release was synced in 0 secs
19:02 -!- CDot1 [n=crawford@crawfordcurrie.plus.com] has joined #twiki_release
19:03 -!- CDot1 changed the topic of #twiki_release to: http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
19:34 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has joined #twiki_release
19:45 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has left #twiki_release []
19:45 -!- EugenMayer [n=EugenMay@dslb-092-074-254-018.pools.arcor-ip.net] has joined #twiki_release
19:45 < EugenMayer> Hello
19:46 < EugenMayer> CDot1: are you arround?
19:48 < OliverKrueger> What time is it in London?
19:49 < gmc> 19:42 i guess
19:49 < gmc> its 20:42 in .nl
19:49 < OliverKrueger> so it starts in 10min?
19:49 < gmc> think so yes.. but we just had wintertime.. so it might all be a mess.. lets check the world clock
19:49 < gmc> i believe cdot is having dinner atm btw
19:50 < OliverKrueger> daylight saving just changed here, too. Thats why Im asking. :)
19:51 < gmc> ah.. ntpd was not running.. it's 8:51 here :)
19:52 < OliverKrueger> 7 mins,... gone forever... ;)
19:52 < gmc> 19:51 in london indeed, according to the/a world clock
19:52 -!- TomBarton [n=TomBarto@63.146.69.17] has joined #twiki_release
19:54 < EugenMayer> Hi Tom
19:55 < EugenMayer> Hi Marcus
19:55 < OliverKrueger> Hi Tom.
19:55 < TomBarton> Hello
19:57 < EugenMayer> So the meating starts in some minutes or am i wrong?
19:58 < gmc> you're not wrong, unless i am too
19:58 -!- Lavr_ [n=donotlik@cpe.atm2-0-103309.0x3ef3d076.albnxx13.customer.tele.dk] has joined #twiki_release
19:58 < EugenMayer> i used the "meating" word again
19:58 -!- SopanShewale [n=chatzill@123.252.224.74] has joined #twiki_release
19:59 < gmc> :)
19:59 < PeterThoeny_> hi andre, crawford, eugen, koen, kenneth, oliver, sopan, sven, tom, markus
19:59 < EugenMayer> i mean, whats wrong? it sounds the same :)
19:59 < EugenMayer> Hi Peter
19:59 < OliverKrueger> Hi Peter.
19:59 < PeterThoeny_> who is actually at the keyboard?
19:59 < Lavr_> Kenneth is
19:59 * gmc <==
19:59 < OliverKrueger> Markus is set to "away".
20:00 < OliverKrueger> so as CDot
20:00 < gmc> i'll be mostly in lurking mode though, i've caught a bug again
20:01 < OliverKrueger> Im busy with some kinosearch issues, too. Please shout, if you want me to comment on something.
20:01 -!- will_t1 [n=wii_t1@63.146.69.17] has joined #twiki_release
20:01 < PeterThoeny_> hi will
20:02 < PeterThoeny_> who will be facilitating? who will be taking notes?
20:03 < PeterThoeny_> proposed agenda items are posted at http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
20:03 < PeterThoeny_> # 1. Review Urgent Bugs - for TWiki 4.2.4
20:03 < PeterThoeny_> # 2. Feature requests for Georgetown Release
20:03 < PeterThoeny_> i would like to start with a new agenda item
20:03 < PeterThoeny_> ---++ Relaunch TWiki.org Project
20:04 < PeterThoeny_> http://twiki.org/cgi-bin/view/Codev/RelaunchTWikiOrgProject
20:04 < PeterThoeny_> please review, i also sent this content to twiki-dev and twiki-announce
20:05 < OliverKrueger> Did you change the default skin?
20:05 < PeterThoeny_> yes
20:05 < PeterThoeny_> that is one of the changes
20:05 < EugenMayer> looks a lot better. Not perfect, but years be

Theony will just alienate himself.

[DragonTHC]

He believes it's his project.

It is not.

It belongs to the mass of developers who contributed to it.

Happily they forked the codebase.

Sadly for Theony, no one will continue using Twiki. His actions are just bad for open source software.

Re:Theony will just alienate himself.

[fm6]

You're making two big assumptions that don't quite work.

First, you're assuming that the fork will become an established product. Possible, but not certain. To survive, an OS project needs leadership — somebody who's willing to take a lot of time to do all the boring administration stuff that keeps any software project moving forward. From what I know about the people involved in the fork, none of them fits the bill. They all have day jobs that have little or nothing to do with TWiki. They just contribute bits and pieces of code in their spare time. Unless somebody emerges to fill the leadership role, this fork is just going to sputter and die — as most forks do.

Second, you're assuming that most of TWiki's users will immediately abandon TWiki and move to the new product. Speaking as a TWiki user, I can tell you that's not going to happen. We use TWiki to maintain corporate applications that have to be reliably available. We can't afford to shift to an unproven new product, even if it uses the same code base. Most users will take a wait-and-see attitude, and maybe shift once the fork proves itself.

Here are possible outcomes, in rough order of probability.

• Both TWiki and the fork wither and die, TWiki from a lack of contributers, the fork from a lack of leadership. That's kind of a pain for those of us who use TWiki, but it's not the end of the world. There are a huge number of OS wiki products. Retooling to use one of them is something I would avoid as long as possible, but which might well pay dividends in the long run, since TWiki is not that great a piece of software.
• Theony's VC partners give him money to hire paid help, and that keeps TWiki alive. How good that is for TWiki users depends on how much they restrict the new code. Most of us just can't afford to pay for this kind of software, so if key features become proprietary, we'll jump ship — maybe to the fork, but more likely to another wiki.
• TWiki dies and the fork takes its place. Easiest for users like me (though not necessarily the best outcome!), but extremely unlikely.

Depended, past tense

[Sockatume]

Now the really hard, expensive part of development is done, the open source community is no longer needed. Now corporate drones can be hired to fix bugs and run the program into the ground with ill-executed new functionality.

Re:ow

[AndrewNeo]

Sorry but that AC right above you asked for it first!

Serious issues with this project

[rapiddescent]

I was in the market for a wiki engine for a top-100 UK company. It seemed, during the investigation phase, that twiki was too good to be true - until we found that the founder and main contributor polluted just about every forum with "use twiki" messages whether it was sensible or not. It met our shortlist and so we installed it, but, it didn't meet our criteria on usability, administration and we found it to be quite slow. I think the 'founder' had raised expectations a little too high on all those forums he posted to...

Certainly, we now have an open source policy that looks into the organisation of the hosting project to look out for these sorts of shenanigans before we use it. Certainly, I think the twiki situation is more about the personality of the 'founder' than anything and I would steer clear of a project that is behaving like this until the project board are more stabilised. it's happened before, and it will happen again.

We went with mediawiki and its been a real success and culture changing event for the organisation - encouraging some of the staff to send in fixes and create extensions to be shared with the community. The success of mediawiki software and the mediawiki project as a whole has now opened up the discussion on Linux, JBoss and other open source platforms in this once closed-source-only organisation.

Mambo/Joomla anyone?

[Qbertino]

Rule Number 1: NEVER get pissy with the majority of main core contributers. If the project has *any* significance at all, you WILL lose. And for very good reasons (and riddance) too. That's a fact. Learn it.

Poor decision...

[mr.dreadful]

This happened a few years ago with Mambo. The company that started Mambo alienated the development community and the developers all left and started Joomla. Today Joomla seems much more robust and viable then Mambo. Twiki.net has a poor road in front of it...

The only good time to do this...

[Kjella]

...or perhaps less bad time, is if you've written so much of the source you can actually rip out any outside contribution, change the license and go down a different road. If you did then it's your project anyway, and nobody promised you'd keep releasing code forever. This on the other hand, sounds like suicide:

20:37 PeterThoeny_, TomBarton: how will you handle our code when we go away? Will it still be there?
20:38 TomBarton of course! we will continue to fully comply with the GPL etc.

So... this will continue to be a GPL project, which means the new community will be free to take any of the VCs improvements and they'll be fighting a GPL project that has most of the previous developers on board? I think that VC might as well flush those money down a toilet or give them to me, either would be a better use of them.

Re:What the hell?

[fm6]

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.