Jump to content

WikidProgramming

From WikiWorld

WikidProgramming is a hypothesised style of collaborative open source software development using Wiki as the source repository rather than say CVS.


Many of the difficulties of collaborative open source software development are multiplied in spades by such an approach. There are conceptual problems to be solved before it can be possible.

Ward's Wiki-In-Hyper-Perl offered an approach to collaborative development of software via a wiki. For various reasons Wiki-In-Hyper-Perl didn't seem to take off as a collaborative project.


The envisioned system would:

  • Have a wiki page for each subroutine.
  • Execute from within your browser (after you have visited a 'start' page) using your choice of technology, Javascript, Java, a downloaded-Plug-in, (your choice depending on your level of paranoia).
  • Give you some choice of versions. For example stable vs cutting-edge.

The intended advantages over conventional development are

  • Lower barrier to entry for participants.
  • Low admin, e.g. no need to separately post tarballs, doxygen documentation and other documentation. Its all there on the wiki.
  • Encourages a document-it-as-you-go approach.

Nice...

ObjectWiki is a different sort of ====WikidProgramming with similar advantages not to meantion is could be used to impliment the sort of !WikidProgramming discribed here.

==


And how does one stop the Code Vandals from coding in 'fdisk /all /yes' or 'rm /s' (yadda yadda blah)?

chroot. we give them a virtual machine where they can only destroy themselves.

Even so there is a deep problem with WikidProgramming; a chroot jail or use of java (without unsafe extensions) will take us some distance towards protecting the machine - but how to prevent both accidental / ignorant/ malicious damage to the set of wikid programs, and keep them open to change?

This is the same underlying problem wiki faces, 'how can it be protected from vandalism?', but its a more critical issue here because programs are more fragile than text.

One suggestion is that each executable 'page' have two 'live' versions - cutting edge vs approved. For a small system approved pages are ultimately approved by the local admin, though he may do this on the basis of voting or other wiki feedback. You can opt to run cutting-edge if you so wish, but normally you would run approved. A common set up would be to run your own server (PWS, Apache or perl httpd) on your own access machine and over-ride pages from the real server with pages from your local server where so desired.