For the more pragmatic ones you might want to look into Fossil SCM by Dr Richard Hipp, author of SQLite.<p><pre><code> * Distributed VCS, tickets and wiki
* You can link artifacts together
* Single statically linked binary
* Works on Linux, Mac and Windows
* Not dependent on Javascript
* Easily themeable, looks good (important, this means you
can slap in the logo and colors from the company web
site and avoid lots of questions.)
* Easily hackable
</code></pre>
(That said, I don't think the template system is aiming for any awards in the near future.)
It seems like almost every project I work on could benefit from a general-purpose library for storing JSON documents along with a change history, including the change timestamp and author. Also the ability to merge two divergent branches and flag merges that need manual attention. I feel like this has been re-invented again and again. It's a bit like embedding git in your application---and maybe that's even the best way to go. It would sure be useful! So I wonder if this Wiki project will have some way to extract just that bit of functionality. The distributed nature makes me thing probably not, but who knows?
I was hoping the next generation of wikis (especially as used by wikipedia) would introduce an underlying 'fact unit' [1] layer on which articles are built, effectively separating edit wars from verification wars.<p>[1] Not the same as a 'knol', which as defined by Google was <i>not</i> a unit. A real knol would be a single atomic fact.
I always have a little weird felling about local storage. I can save stuff on my computer but I don't know where it is going, so I can't back it up nor can I keep it if I format the computer.
Great Project!! The user experience on the page is quite nice--a bit like Trello crossed with GitHub; turning traditionally static wiki content into interactive content.<p>On a related note, I'm curious to hear what others think about the trend of sending data over-the-wire and rendering HTML on the client. I just started working with Meteor, coming from a traditional web development background, and I see major benefits regarding multi-device rendering and real-time updates. However, I'm still on the fence regarding this paradigm and continue building new projects with traditional server-side rendering and DOM manipulation.<p>Playing with federated wiki is very convincing that data over-the-wire is the future.
You can find the previous discussion about this (from last month) here: <a href="https://news.ycombinator.com/item?id=8983158" rel="nofollow">https://news.ycombinator.com/item?id=8983158</a>
The side by side articles reminds me of TiddlyWiki - a self-contained personal wiki.<p>It's a feature I would like to see more use of, as the context of a subject is often spread across multiple pages.
We've been working on a similar idea for a few years now. We have a distributed version called P2Pedia: <a href="http://www.nmai.ca/research-projects/universal-peer-to-peer/p2pedia" rel="nofollow">http://www.nmai.ca/research-projects/universal-peer-to-peer/...</a><p>and a centralized version as a Moodle plugin called Social Wiki: <a href="http://www.nmai.ca/research-projects/socialwiki" rel="nofollow">http://www.nmai.ca/research-projects/socialwiki</a><p>You can try out Social Wiki online (there's a link to a demo site on the above link).<p>The UI needs work, but I'd say Social Wiki is functional. Just need to install Moodle first.
"<i>A conventional wiki, says Mike Caulfield, is "a relentless consensus engine." A federated wiki may eventually yield consensus, but it promotes what Ward Cunningham calls a chorus of voices.</i>"