Anyonecanedit.org

Danny posted on his blog a piece about Fair Use within Wikipedia. While I don’t want to respond to the entire thing, he did raise one question that I feel deserves some mention:

“And to any developers out there, would you allow any non-free components to be incorporated in the wiki-software as well, or can they only be allowed in content? If so, why?”

For those unaware, MediaWiki is available under the GNU General Public License (GPL). It is 100% free, maintained by a host of (mostly) volunteer developers. I believe–and I’m willing to be corrected if wrong–that most of the developers are pretty much committed to FOSS. As MediaWiki is GPL (minus a few parts that are PD), the entire source of it is free. However, we do depend on several external software packages, all of which are free as well

• Web server – Apache or Lighttpd are the recommended web server packages for running MediaWiki. Both are free (Apache under the Apache License, and Lighttpd under the BSD License)
• PHP – PHP is also free, available under the PHP License
• A database – mySQL is the primary DBMS supported in MW, with PostgreSQL also having support. Experimental SQLLite, Oracle and MSSQL support also exists. All of these DBMSs are either completely free or have a free version

That’s it. That’s the base level of software required to run MediaWiki, all of which is free. There are also several extra features that can be enabled (such as thumbnailing with ImageMagick, integration with Subversion via CodeReview, authentication with LDAP, or caching with Memecached) also relying on open source technologies. By and large, MediaWiki is free from external dependencies (the code is mostly in-house, rather than depending on a lot of PEAR modules or frameworks like Zend or Solar). One notable dependency is the Memcached class, which was written by Ryan Dean and is available for free.

In short: I don’t think you’ll ever see it. If one were to try and integrate proprietary code into MediaWiki, I honestly couldn’t see the development community accepting such a change–both technically and from a FOSS standpoint. Our opinions on fair use media may differ, but I think we by-and-large agree on the free aspect of MediaWiki. I personally wouldn’t have it any other way.

I hate buzzwords

Tim Starling, paid Mediawiki developer and systems administrator at the Wikimedia Foundation has launched a blog. And what a launch it is: starting with a very detailed post on file uploading. Here’s to many more posts like it.

It’s certainly worth a read.

Let me begin by saying I love Wikitext. It’s not pretty, but hell if it doesn’t get the job done. There’s been a lot of talk floating around (especially in light of this grant to improve usability in MediaWiki, which I am 100% for) about trying to get a WYSIWYG working–to acceptable standards–to help lower the bar to contribution.

I hate WYSIWYGs. Granted, I’m also a developer, but I’ve never felt that a WYSIWYG ever gets you as close to what you want as editing the raw source (and hence, I’d be opposed to any solution that took away raw editing and forced a WYSIWYG). I’m not the first to say it, but WYSIWYGs are a misnomer. You will never “get” what you “saw.” However, you’ll get a pretty good approximation of what you meant for it to do. I suppose for basic editing, this is good enough. Bold, italic, that kind of thing is easy to reimplement in a new interface for editing. It gets a whole lot harder when you start adding more complex things, such as tables, templates and other block-level elements.

Unfortunately, without a well-defined grammar (see bug 7), it gets really really hard to do back-and-forth translation of wikitext. Right now, wikitext parsing is a 1 way move. We can turn wikitext into XHTML, but we cannot go the other way. Given a block of arbitrary XHTML, we cannot turn it into appropriate wikitext. This is a bad thing and makes developing a WYSIWYWLTG (What-you-see-is-what-you’d-like-to-get) much harder.

In other wiki news, we’ve got a nice discussion going on on a previous post. Trying to make the ForeignApiRepo more fault-tolerant. Right now, when it fails, it fails hard. Graceful failings are nicer to end users.