Welcome to the WikiRing Blog. This is where the partners talk about what we're working on or thinking about.
Here's a video that I still find particularly funny, even though it seems a bit outdated, not only because of its retro look&feel.
My favorite line:It's not what your wiki can do for you but what you can do for your wiki.The size of the blogospehere, that is the number of traditional blog sites out there, seems to be decreasing. At least that's what it feels to me. By no means am I able to come up with some real numbers of the size of the blogosphere. Yet still it is an ongoing process facing the rise of social platforms.
It might also be the case that blogs'n wikis are a known technology nobody talks about anymore, taking them for granted, not thrilling anybody anymore. Or is it simply too much of a hassle to come up with a well written story regularly? It is so much easier to crank out 140 chars of status updates.
Another factor is mobile devices: nobody is enjoying typing into these cuties. Smartphones, the bulk of mobile devices, are bad for reading lengthy texts anyway. That's were tables come in: they make good reading devices, yet still no good content producing tools. Producing good content as a writer is quite a different task compared to reading the result as I recently commented on Karen McGrane's column about creating editing tools. Likewise mobile devices are good reading tools - more or less - while particularly bad supporting the authoring process by nature. And that's not only the case because we are lacking good content editors but for the fact that these devices have no keyboard, simple as it is.At best, people type in a few lines of a status update or comment on somebody else's one. Seriously, nobody could be bothered typing more on mobile devices. So the rise of mobile internet also plays a factor in the fall of blogs as far as I can see. Or are there any good mobile blogging apps out there that people use regularly?
Let's face it: the debate Blogs vs Wikis is no more. Both paradigms are facing a third one, the social platforms à la Facebook and friends. It is more a "Blogs and Wikis vs Facebook" debate (replace Facebook with your favorite social platform). It comes with a significantly different approach to sharing information being centered around people whereas blogs and wikis are centered around documents. That's the debate to follow: document vs user centric. The very same discussion is coined "old school vs new school knowledge management" on other occasions. In the end what's all the knowledge worth it without people using it. Each act of sharing knowledge on a blog, wiki of wherever is a social interaction with other people. Otherwise you could keep your thoughts for yourself. So putting people at the core of knowledge management instead of the documents that they share does make a lot of sense. As far as I see it, there is still a strong point in giving documents a structured place to live at, so people know they are "there". The central organization principle on social platforms - activity streams - feel too much in flux to be able to capture valuable knowledge long term. There are even cognitive limitations to consider when establishing a regime of activity streams. They have their strength, no doubt, as long as people show activities using it. All of the mentioned tools suffer from the adoption problem on the intranet facing low numbers of users and very homogeneous content types. Intranet is not big data you could mine for whatever purpose, it is all about metadata, mostly handcrafted. Blogs are a very static activity stream if you want so, a linear order of articles. Wikis are more of a sack of things that don't have an aging factor. Blog postings as well as status message have this in common: they age and fade out in the past. Wikis don't age well, you have to review content and see if it is still relevant. But that's a very important process anyway to manage the quality of your content. No such thing is required on activity streams. They come and go automatically. People use it as an email replacement. When they have a question they ask again even though the very same question has been answered already somewhere down the stream. Retrieving it would take more time than asking again, a property that activity streams have in common with forums. Does anybody still use forums these days? … moreFor a long time we've talked about stitching a relational database into Foswiki, mainly to speed up query searches. To keep things simple Foswiki uses a text database, which stores topics in lots of individual files. By default, searches are implemented by searching every one of these files individually for matching text. This isn't as bad as it sounds; searching is surprisingly fast. But it doesn't scale up terribly well, so people have coupled in various full-text search engines, such as Kinosearch, to accelerate text searches.
However there's been very little successful work yet on speeding up query searches - which is a shame, because query searches are heavily used in most wiki applications. The problem has always been that it's difficult to map from a Foswiki search query to any kind of structured search language, such as SQL.
One approach (championed by WikiRing member Sven Dowideit) has been to support a wider range of queries in the text search engine. Using the code I wrote to map query searches to regular expressions, Sven has been able to couple Foswiki to the MongoDB database, with some pretty impressive results. This is already available as the MongoDBPlugin. Other approaches have tried to map Foswiki queries to other database search models, such as XQuery, but with little success. SQL is still the most common query language, and the RDBMS that support it are among some of the most mature and robust software on the planet. It's important that Foswiki has solutions that fall into that comfort zone. To that end I have implemented a new module, the DBIStoreContrib, that maps from the Foswiki query language to SQL. This allows us to use many of the existing RDBMS, such as MySQL, SQLite and PostgreSQL, to accelerate queries. By caching topics into the database in parallel to the text database, we avoid the risk of data loss that has made people nervous of other wiki solutions that use RDBMS, such as Mediawiki, while still maximising search performance.It's early days for this module, and there's still lots to do to optimise how it works, so watch this space! If you are interested, and have a development environment, then you can check out the DBIStoreContrib from the Foswiki Subversion trunk.
Foswiki - the very best wiki application platform - is taking another giant leap forward.... … moreWhat is legally permissible when adding a copyright notice to a derivative work?
In 2008 I stopped contributing to an open source project when it was pwned by a commercial interest. At that time a number of my original works existed in their source code repository, and still exist there pretty much as I left them 2 years ago, when I moved further development to a different repository. All of these works were released under the GPL, and carry my personal copyright notice, or that of a wider group of contributors who had worked on the project up to that date. Since I left the project, the now-owners have redefined that contributors group, and have taken to retrospectively applying a different copyright to a number of these works. They have made some minor changes (mostly removing my personal branding, but also adding some scraps of new documentation) and added a dated copyright notice of their own that extends their claim back several years, despite the fact that (according to their own public records) no changes have been made until very recently.Now, all the code and documentation is in their source code repository, so I would have no problem proving that I am the original copyright holder. However by making some very small changes, they have technically created a derivative work, and I don't have any problem with them adding a copyright notice to cover these new changes.
But what I find really objectionable is the dating of that new copyright notice back to a point well before the changes (5 years before, in at least one case).This is obviously immoral, but the question is, is it actually illegal?
Update: it has come to light that in at least one case (not my code) the new copyright notice has been extended back to a date before the work was first published. I'm not sure whether to laugh or cry! … moreThat's great for working with attachments, but what about topics? Up to now, if you wanted to edit a topic, you had to edit the raw Topic Markup Language (TML) that the topic was stored in. Using Microsoft Word to edit TML is like using the space shuttle to commute 2km to work. Life would be much simpler if we could feed Word with a format it understands, like HTML.
We've been able to WYSIWYG edit Foswiki topics in the browser for a long time now; so the technology to convert topic content to other formats and back again exists; all we needed was a way to present this through WebDAV.
What we need to do is to give the WebDAV user a way to select what format they want the topic in. We've done this by allowing the same topic content to be mapped to more than one file entry in a WebDAV directory listing; each file entry is referred to as a "view" (because it's just a different way of looking at the same data). The FilesysVirtualPlugin is configured with a list of views that it supports; for example, txt, html, json. When it is asked for a list of files in a Foswiki web, it generates a file entry for each of the different views, so the topicMyTopic
ends up with the entries:
MyTopic.txt
MyTopic.html
MyTopic.json
txt
, html
, and raw
, two meta-data views have been provided, json
and perl
. These views allow you access to topic meta-data. It's easy to add new views, and we foresee other useful view types, such as xml
and yaml
coming along later.
WebDAVContrib, FilesysVirtualPlugin and the companion WebDAVLinkPlugin are available from Kontextwork. … more
It is often claimed that only a few developers moved from TWiki to Foswiki, therefore the first article will look at who are/were active core developers of both projects.
"We have healthy downloads, an active user community, and a very active support community. However, we are a smaller developer community than we used to be."
Source: Blog post by Peter Thoeny (Twiki.net) - 11 Nov 2009
Developers of TWiki and Foswiki | ||
---|---|---|
![]() |
![]() |
|
Core contributers | ||
PeterThoeny | ||
SopanShewale | ||
CrawfordCurrie | ![]() |
CrawfordCurrie |
KoenMartens | ![]() |
KoenMartens |
MichaelDaum | ![]() |
MichaelDaum |
RafaelAlvarez | ![]() |
RafaelAlvarez |
AndreUlrich | ![]() |
AndreUlrich |
TravisBarker | ![]() |
TravisBarker |
ArthurClemens | ![]() |
ArthurClemens |
GilmarSantosJr | ![]() |
GilmarSantosJr |
LynnwoodBrown | ![]() |
LynnwoodBrown |
OliverKrueger | ![]() |
OliverKrueger |
ColasNahaboo | ![]() |
ColasNahaboo |
KennethLavrsen | ![]() |
KennethLavrsen |
MarkusUeberall | ![]() |
MarkusUeberall |
SvenDowideit | ![]() |
SvenDowideit |
AntonioTerceiro | ![]() |
AntonioTerceiro |
WillNorris | ![]() |
WillNorris |
MartinCleaver | ![]() |
MartinCleaver |
New to core development | ||
SebastianKlus | ![]() |
SebastianKlus |
OlivierRaginel | ![]() |
OlivierRaginel |
EugenMayer | ![]() |
EugenMayer |
LarsEik | ![]() |
LarsEik |
IsaacLin | ![]() |
IsaacLin |
GeorgeClark | ![]() |
GeorgeClark |
AndrewJones | ![]() |
AndrewJones |
New developers | ||
![]() |
SeanMcCarthy | |
![]() |
RobManson | |
![]() |
BenBeijer | |
![]() |
RaulFRodriguez | |
![]() |
MarkSchumann | |
![]() |
MichaelTempest | |
![]() |
AndrewPantyukhin | |
![]() |
DrakeDiedrich | |
![]() |
PaulHarvey | |
2 Core Contributers | 32 Core Contributers |
Number of core contributors | ||
---|---|---|
before commercial takeover of System.org (2008-10-27) |
one year later (2009-10-27) | |
System.org | 18 | 2 |
Foswiki.org | n/a | 32 |