Oddwiki

Odd Wiki, the mother of some wikis oddwiki
A wiki-hive, also known as OddWiki
A MotherWiki.

An experiment in quick-n-dirty wiki creation running Oddmuse with namespaces. AlexSchroeder eventually wanted to shut it down because of WikiSpam:

  1. it’s hard to fight WikiSpam on wikis that aren’t yours
  2. spammers figured out to create a new wiki for every spam page

MattisManzel decided that it was worth saving and you can still find OddWiki on his server:

Why?

Oddwiki is a MotherWiki – trying to help people use a wiki without installing one. Once they know they like it, they can set up their own system and migrate the existing pages.

If you already have a wiki, there’s no need to use Oddwiki.

Why is an ordinary test wiki not enough? Usually test wikis accumulate data garbage at an astounding rate. Test pages, “Hello World”, spam, it all comes together. If the wiki documentation is kept on the same system, this deteriorates user experience. Oddwiki gives every user their own wiki to play with: Their own namespace, spam-fighting infrastructure, a decent set of features, and the option to leave at any time and take the pages with you. No lock-in.

Oddwiki is a cool wiki-hive. Don’t hesitate to use it, please. It’s the fastest and most open way to create a properly spam-protected wiki today. Oddwiki and OddMuse simply rock.

First; I feel compelled to say that I am extremely impressed by this software. I almost feel that it was written just for me, since the functions and features given that Alex has incorporated are ones that I am particularly dependant upon, as a long-time user of WxWikiServer; specifially …

  • an elegant (even if “limited” TransClusion facility
  • Regular Expressions that drive Collections - making it really efficient to use MicroContent concepts.
  • an independant InterMap, making it possible to make source much more portable in recognition of the fact that all software has a “shelf-live” and requires maintenance and enhancements to remain attractive to its user base.
  • CSS style sheets.
  • etc …

Second; I’ve pretty well decided that I really want to use Oddmuse software for several of my business projects. For me, this requires reliable access to the content. With the result that we have copies running in on multiple production server-farms used in my endeavours. Ideally, I would like to have this mirrored into at least two countries and probably four (CA, US, EU, and an Asian one - perhaps China), as quickly as possible. Obviously, bandwidth is a concern to everyone. At present, I have access to a minimum two independant 100 megabit pipes, which are almost always less than 20% used, although I’m, told we recently spiked to 45% for 48 hours. We seldom use more than 40% of the 100 megabytes per month minimum that we pay for, and can easily acquire more, dynamically, just by paying for it. I am stating all of this simply so that people can understand my current definitions of “adequate” and “reliable”. What I do not have’ is … PERL expertise! Nor can I easily justify acquiring enough of it to install and maintain the software, no matter how easy this might be. I can contribute routine “admin” efforts (not my own, but I have reliable people at my disposal that can do routine things that do not require specific technical expertise.)

Finally, to the extent that the Oddmuse software allows us all to ‘co-exist’, I would be pleased to let others share the environment. I probably have acquired a high-enough TrustMetric, that I can state “I have no intention of becoming a GodKing, BenevolentDictator, etc … what so ever. Besides, “limited” TransClusion and the …copy:http:… automated syncs make this concern obsolete, in my opinion.

And, in conclusion, there has been a great deal said about Community Governance. For the record, I am strongly in favour of having this defined as a Contract, if only because I am quite used to having such a document with the Clients I serve. More importantly, however, I believe that Trust is a function of meeting expectations and that these should always be clarified to the extent practical. i.e. written down, either as a Service Level Agreement in some other Contractual format. To that extent, I believe the view stated by Lion and others that this is the prerequisite “next step”; is right.

So, Hans, you must have gained at least some basic Perl knowledge, because, unless I am mistaken, you were able to install this on a server and get it working.

Perl is not as hard as I thought it would be, and is actually more readable than other scripting languages, like PHP, for instance. That is just my opinion.

I personally only have a ‘rudimentary’ knowledge of perl, but that was more than adequate to direct the installation and participate by setting many of the script variables, etc… just based on what I know of OddMuse from using it in multiple wiki environments and generally from other wikis.

From what I’ve seen of perl so far, its a perfectly adequate “turing complete” language that has one of the largest function libraries of any language that I’ve encountered. This makes it relatively easy for an advanced amateur like me to code in it, but only as an amateur, for my own personal use. At this stage, its simply more effective for me to pay professionals when I need them to do “production” work than to “do it myself”.

At present there are three separate WikiHives? in production and I’ve already lost count of the number of SubWikis?.

  • One interesting “trick” is that we’ve hacked the biggest to be a “Private” wiki by hooking into the SurgeProtection? module. This works by redirecting any and all read attempts to a “public” SubWiki, unless a single, centralized login page is used to request an authentication cookie, via a password.
  • I am still not comfortable that we have structured the “hive” aspects properly. For example, the communitywiki..odd… SubWikis? obviously support individual sets of Admin and Editor passwords, while the script only provide for a single master set. I suspect that there is a trick to the way the two levels of the MAIN and SubWiki namespaces are “layered”, but I’ve been more concerned with structuring the content than I have the technology, so I simply haven’t had time to direct the investigation into what we may be doing wrong, yet.

All in all, I remain very impressed by the practical balance features and code Alex has achieved with this “light weight” wiki (in comparison to the relatively “bloated” functions of MediaWiki). Obviously the inconsistencies that cause various modules to “clash” as well as the various CSS pages to “fail” suggest that there are opportunities for improvement, but frankly, that’s something that we have put on our “back burner” for now.

Hehe, clashing modules and CSS fail is annoying, certainly. But, just like you, I’ve been putting things that I don’t use myself on a back burner—in perpetuity, aparently, hehe.

Why Not?

The spam problem needs a solution that wasn’t forthcoming.

In addition to that, I didn’t use it on a daily basis. That’s why I eventually cared less about the modules installed, the text formatting rules, the documentation. The design wasn’t timeless and I was unwilling to work on it.

Heh. Makes sense to me. 😊

It turns out that Mattis was so invested in it all, he got himself a server, I installed all the necessary stuff and now it is entirely in his hands! Go, Mattis! 😊

Confirmed. It’s http://oddwiki.org. Thanks a lot, Alex! That was a fast and encouraging beginning. Still to be moved are http://kabowiki.org, http://obmwiki.org, http://eartwiki.org and http://dikiwiki.org. I’ll send a message in a bottle when drowning in spam …

I’m delighted, if only because I wasn’t able to get all of my content off.


CategoryExperiment? DossierExpérience?

Define external redirect: CategoryExperiment SurgeProtection SubWikis DossierExpérience WikiHives

EditNearLinks: TrustMetric BenevolentDictator MediaWiki WxWikiServer GodKing

Languages: