Slashdot Log In
TWiki.net Kicks Out All TWiki Contributors
Posted by
CmdrTaco
on Wed Oct 29, 2008 10:14 AM
from the what-does-that-mean dept.
from the what-does-that-mean dept.
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?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Answer: (Score:3, Insightful)
You make a good point... (Score:5, Funny)
but on the other hand, yes.
Parent
Re: (Score:2)
Re:You make a good point... (Score:5, Insightful)
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.
Parent
Re:You make a good point... (Score:4, Insightful)
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.
Parent
Re: (Score:3, Insightful)
It is hard for the employee to apply specific knowledge of something like Windows or PhotoShop to another project.
More importantly it's easy for an OSS programmer to apply what he knows about the Linux kernel from one job to his next job where the Linux kernel is the topic of programing work. It's easy to apply experience programming the GIMP, even exact function names and their implementations, to another job improving the GIMP. It's even easy to take code directly from one of these projects and use it in
Re:You make a good point... (Score:5, Interesting)
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.
Parent
Re: (Score:3, Insightful)
Re:You make a good point... (Score:5, Insightful)
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.
Parent
Re:You make a good point... (Score:5, Insightful)
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.
Parent
Re:You make a good point... (Score:4, Funny)
Yep.
Sounds about right to me...
Parent
Re: (Score:3, Interesting)
Isn't the whole point of free software to limit the impact of this kind of decision? Part of the maximization of freedom is the freedom to stop working with other developers, both the freedom to fork, and the freedom to force others to fork.
If the core developers have the source code, and rights to that source code we are talking about, potentially, three things of value: (1) the project name and (2) access to the source code server and by extension (3) access to the source archives. Of these, the only se
Re: (Score:2, Insightful)
Yes.
Stealing other people's work is a very effective strategy to succeed in business without really trying. Look at Microsoft.
Long Answer (Score:2, Interesting)
Another strategy is to never let the "community" in. Look at Alfresco. They get lots of press and kudos for being open source, but are very protective of their code and don't let contributors in. But they keep the "community" gathered outside their gates because they've never done anything to alienate them. They just started out as somewhat hostile and will never get flak for staying that way.
They only other similarly managed project that pops to mind for me right now is Liferay.
set up .wiki (Score:2)
Make it a tld. Post the nameservers here. That is if it's a usefull tool. If you jsut want to speculate on the names the line forms at the right over by the icann booth.
Re: (Score:2)
Yes.
Stealing other people's work is a very effective strategy to succeed in business without really trying. Get free work, then package it as retail software, and $profit$.
Server logs reveal real reason for lockout (Score:4, Funny)
bidi-bidi-bidi bidi-bidi-bidi bidi-bidi-bidi...
Re: (Score:2, Funny)
how the buck rogers is this off topic?
Twiki blows (Score:5, Interesting)
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: (Score:2)
indeed. And this without counting the rather bizarre programming model it uses for the Twiki Apps. It probably deserves an entry in the Turing tar pit. *shudder*.
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.
Parent
Re: (Score:3, Funny)
True, but you should also be able to run a popular web application on something less hardened than an OpenBSD server configured by a paranoid schizophrenic.
...but you repeat yourself!
Re:Twiki blows (Score:4, Funny)
It looks like then that they're well on their way to becoming a respected piece of enterprise software.
Parent
Re: (Score:3, Interesting)
We switched fro twiki to DekiWiki and are mostly pleased. Deki has a rich-text editor (no wiki mark-up to learn). It also integrates with Active Directory and does other neat enterprisey things.
On the downside, Deki absolutely chokes if you try and cut-n-paste into it from other applications. I hope they fix that. If you switch to Deki, be prepared to fight with formatting a lot, including editing HTML directly to figure out why making one word bold makes the entire paragraph bold.
What the hell? (Score:2, Insightful)
If you have a community, you don't piss them off like this, for exactly this reason. They will kill you in the press.
Every project that goes commercial (MySQL, I'm looking at you) has a heritage of open source. By killing off the community that created it, they are going to kill off their commercial prospects.
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.
Parent
Will Sun take back their servers? (Score:2, Interesting)
After RTFA it appears that Sun donated a few servers to host twiki.. Will they be taking them back now that the arrangement has changed (or will the venture folks end up paying for them)?
Either way, pretty stupid way of doing things, worse than XFree86 even, especially for a GPL project...
Welcome to the new economy (Score:2)
With less money to throw around, VCs will expect some immediate payoff for any investment they make in a project.
I hate to sound like a troll, but it looks like we may see the end of a marriage between what we believe an open source projects should look like and the venture capitalists that fund them.
I still think open source will continue to thrive in the government/academic markets. It's just experiencing a little push back from commercial capital...
Re: (Score:3, Informative)
Re: (Score:2)
Not all Open Source projects are funded by venture capital! I work for a small company that has several Open Source projects out there, and has never had outside capital. We've had our bad times, but at the moment we are expanding slowly, and the future does not look too bad.
(And yes, we use Twiki internally, and I
ow (Score:2)
Re:ow (Score:5, Funny)
Parent
Wrong logs (Score:5, Informative)
Re:Wrong logs (Score:5, Interesting)
--- 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
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
Parent
Theony will just alienate himself. (Score:5, Insightful)
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. (Score:5, Insightful)
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.
Parent
Depended, past tense (Score:5, Insightful)
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?
Question assumes the answer (Score:2)
Of course, the question presumes the answer. If, in fact, the VC firm depends on a healthy Open Source community, it shouldn't lock it out. The real question is does the VC firm (or, as I think would more accurately state the case here, the VC-funded firm) actually rely on that, or is it viable for them to operate without it?
Serious issues with this project (Score:5, Insightful)
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.
Go With The Flow Or Don't (Score:2, Flamebait)
"Is it a sensible move for a venture capital firm that depends on a healthy Open Source community to lock it out?"
They didn't. TFA states several moved to the new project with the VC. Since there's a backer, they should be able to say what they support. If they wish to change, they can. If others want to change with them, they can, and have. If others don't want to, simply because the backer closed the old project, they don't have to. They don't have to grow up and accept the fact they'd been participating
Mambo/Joomla anyone? (Score:5, Insightful)
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... (Score:4, Informative)
Cheeky (slightly off topic/topic hijack...) (Score:2)
I've recently been fiddling with Twiki, and looking at structured wikis in general.
I've been looking at ways to build collaborated structured data... where the structure of the data (i.e. the sort of fields that need to be filled in) evolves over time - and where some form of editorial control can allow the reliability of data to improve over time... or, at least, allow several people to come to agree on the same false data.
I've not been getting very far very quickly - though Drupal is showing some promise.
The only good time to do this... (Score:4, Interesting)
...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.
TWIKI (Score:3, Interesting)
Is it just me or does anyone else remember Buck Rogers from the 70's? The robot character was Twiki... I wonder if that show got a trademark on 'TWIKI' and if so, what would happen to the TWIKI.NET trademark?
Trademarks don't work that way (Score:3, Informative)
Does it really matter (Score:3, Interesting)
considering that among real Wikis, TWiki is crap?
TWiki's business model revolves around wowing lazy, barely-competent middle managers who will never really use the thing and foisting it on hapless employees while looking tech-savvy to upper management.
AltTwikiDieDieDie.
Re:Personal crap. (Score:5, Funny)
Parent
Re: (Score:2)
Bad taste in IRC? Never heard of such a thing. [bash.org]