Slashdot Mirror
The Importance of Collaborative Development
Eugene Eric Kim writes: "A few months ago, I wrote an essay entitled, "A Manifesto for
Collaborative Tools," outlining a vision for how we can and should be
making collaborative tools more interoperable. The article was
published in the May issue of Dr. Dobb's Journal and is now available
on the web." This manifesto is a good one, particularly if you aren't as a familiar with Doug Engelbart as you should be. There's also some interesting links to learn more about the Semantic Web, and social networks, well worth checking out as well.
...check out SemWebCentral, which is a GForge installation hosting a fair number of Semantic Web-related projects. There's even an OWL mode for Emacs!
And there are also some tutorials and such-like.
The Army reading list
I have made a Collaborative Tools
which i call eigenpolls
Check it out.
I don't know about your workplace environment, but my company has locked down shares and peering due to the fact that this an infection vector.
I think peering/collaboration is the way to go, but this is becoming increasingly difficult thanks to the lax default permissions that was inside windows (yeah I'm not a windows admin, and the default share was always set at world full access). The knee jerk reaction was to disallow *all* peer/sharing.
I'll probably get ripped and modded to hell for this but I was looking forward to the "hive" type setups that MS was proposing for peering(for work this would be a godsend, I wouldn't do this at home tho). My concern was their security model.
Just how in the hell can this be done when virii explicitly target this functionality? CVS / Subversion is not an answer for business/end users...
B
This is one of the most important things in creating any product. I have seen in software and engineering, programs and products created that were technically really cool but didn't fulfil what the "people" wanted.
Creating applications that are people-centric are key. They can make or break a product. I use an app that has a few bigt bugs but it was designed to be people-centric so I still love it. It was coded horribly, has crashed for some dumb reasons but how it was designed is great. (A note, I am working with the author to iron out those bugs)
Evolution or ID?
Having more than one person on a project helps
a whole lot. Especially when you have people
with different skills that are all good coders.
I'm working on a "hobby" project right now, where
we have 1 person that does alot of the major coding
because he is really good with the catagory the
software falls into. Another person codes the
UIs, and I do alot of other work, planning and
support (I coded the network classes for our
project, for example). Things are working quite
well, it's been really nice.
Is there actually any proposal as to how this is done?
The manifesto makes grand claims about unifying our collaborative language, but totally understates how difficult this is. The problem usually is that we just do not have a solid model of what can and cannot be done, and we likely never will.
The author pointed at SQL as an incredibly important standard for how data is handled. However, relational databases are relatively simple. We know most everything they can do, so we can define it. And, even, with that, databases are not entirely standard. Most databases have their own little features, often not in the standard.
Look at another good example: filesystem structure. Despite how well defined the Filesystem Hierarchy Standard is, distros still tend to be non-compliant. It's an incredibly simple system, and we can't even reliably follow it. Is aiming at standardized interfaces between collaborative applications truly reasonable?
Hopefully, a few things can be standardized, as they are recognized as being universally useful. Some basically are. For example, e-mail is e-mail. There's not too much more to it. Maybe we can slowly define those things which we understand and see the importance for, but moving much beyond that is likely infeasible.
Oh - and you're way off topic, btw. RTFA =)
MediaWiki in particular implements many ideas that were already envisioned by Ted Nelson and Doug Engelbart. It does show backlinks, but perhaps more importantly, it also allows dynamic inclusion of any page in the current development version. For example, you could have a header and footer in your documentation that is the same for every page. What's more, you can add parameters to these templates to dynamically search and replace patterns of text in the template before transcluding it. This will allow us to replace the currently statically hacked Wikipedia infoboxes with dynamically included and parametrized templates, for example. One long term feature that might be worth hacking on top of this would be transclusion of labeled sections from another page, or interwiki transclusion.
Check out the current feature list and the development roadmap. Subscribe to wikitech-l to help us in improving the software. In true wiki spirit, we are fairly liberal at handing out CVS access (over 40 developers with CVS access at present), so please do ask if you want to work on a larger project.
There are many other wiki engines that are worth working on, such as TWiki and MoinMoin. Their main deficiency, in my opinion, is that they do rely primarily on the traditional wiki link pattern of CamelCase, which is nice for geeks but very ugly for everyone else, and also useless for search engines. MediaWiki uses [[free links]] instead, which are harder to type, but look just like normal links to the reader. Still, working on any other wiki engine is a lot better than starting yet another one.
A collaborative tool which is badly needed is a free software clone of SubEthaEdit. Combine wikis with real-time editing and the fun really begins. I imagine something like that might be hackable on top of a powerful graphical editor like Kate. For now WebDAV-support for MediaWiki would also be very cool, as Kate/KDE already supports editing WebDAV resources. So many worthwhile hacks, so little time.
This is an area where open source coders can make a big difference while corporations are still bewildered by the fact that open wikis can produce useful content. So please, let's work together on these tools.
Doing everything via a share would require a massive amount of permission adjustments that users just can't handle easily. Not to mention, file systems are only useful when two users are on the same network. An internet filesystem is simply not practicle enough to use on a daily basis. This may be one place where Internet2 might show us what's possible.
Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose.
...reading this very article over breakfast and I was thinking: why something like this is not discussed on Slashdot instead of the recent crap!
The average user needs to be able to create the docs and the tools need to do the colaboration. It has to happen way before the the save-as menu option. It also needs to happen with out the users even knowing it is happening.
I also think that the whole "document as a file" scheme needs to go away. The printed copy needs to have watermarked inside it the version and date it was created / printed. But the document is an ever changing entity that should be accessable and modified but not saved as a file. As soon as someone has a portable, editable file, the whole system is broken. Just like the floppy breaks the network.
CVS et al. needs to be done at some level so that the user never even knows it is happening. I believe that the whole co-laboration methods that we have currently are great for programers and techies but the average user is still shaking their heads in confusion. Just like what the average user is thinking about public key encryption.
I am now working on an OSS project with a lot of these ideas in mind.
Discourse District
A dynamic repository for community writings, a mirror, mapping the writing community.
(the link above points to an abstract, the link to the system is at the bottom)
basically it is a wiki adaptation with touchgraph interface, that is meant to be a community utilized concept map.
Born out of a need to define the Complexity community, its scope, and the fact that no one person could define it , since everybody else would disagree.
This way the community would be defined by anyone adding their activities, and a graphical map would be a new form of definition
That number again '0'(Chief Wiggham)
I am new to this and would appreciate your comments on
1. Concepts
2. UI
3. publication
4. that stupid IE6 SP0 bug on calling an applet from the contatining page and getting the width...
-- Avishalom is usually vish
By having a set of Markup layers, gets much easier to see and manage comments, etc. Ideally, you should be able to simply toggle each layer of markup on and off, just like a mutli-layer image in PhotoShop or Paint Shop Pro.
Some day we'll get real Hypertext, but we're defintely not there yet, and XML isn't it either.
--Mike--