This page is dedicated to the Goofy-project, where the possibilities of using a wiki-system, as a software development environment is investigated.


The project is (temporarily) being named Goofy after the wackie figure in Disney's universe. This name is chosen because it says something of the chaotic nature of the wiki-system.
Other name-ideas can be added here.


The vision of this project is to make it possible to develop a software project in a wiki-system, where everyone can contribute to the finished software. This would make Mob-development (what is Mob-dev? -- Mobile Development?) truly possible, and perhaps result in better software.

Develop software by the use of a wiki-system#

Many of the features of a wiki-system makes it ideal as a software development tool:
  • more people can work on the same project,
  • errors (bugs) can easily be corrected by the end users,
  • its extremely easy to use, so the concept of Mob-development can actually be made possible.

Todays open-source projects are developed by very few volunteers, because the only way to contribute is through "difficult" systems like CVS, or like this project, through email-contributions. The chaos this would bring is maybe what is needed to bring the software development just a step forward. (See Feyerabend)

To implement this the following features must be added:

  • Possibility of correcting code,
  • Possibility of testing the implemented code.

I admit that this idea is way out, but just look at how fast and bugfree things like WikiPedia has been developed. Maybe the concepts of that can be used in software engineering to.

Needed features#

As a software project is developed the developer first comes up with some ideas, then they develop these ideas, while maybe documenting some of the code. After some development the software is tested and used. The aim of this project is to make it so easy to develop the software, that this can even be done by the end users. To make this possible the following features are needed:
  • Possibility of coding directly in a wiki-environment.
  • Possibility of compiling and testing the code in the environment (like "preview").
  • Tree-like file-system structure. (via left Menu?), possibility to traverse the src code tree. --Rue
  • ...(Add more) .

A possible implementation#

I just stumbled on this page when searching for "wiki code version control" -- yep, same idea! I'm going to try and implement this for an ActionScript library I am developing. I've already created a WYSIWYG Wiki for (launches Jan 1st, 2003.)

Basically, and as outlined above, this will be a Wiki with a custom editor control suited for code (with auto-complete?). I'm favoring the use of Flash for the editor to make sure its cross-platform (the WYSIWYG Wiki, for example uses a Win/IE only control called htmlArea.)

- Aral


A few thoughts about this:

What we have:#

  • easy to use web frontend
  • versioned content on a per-page basis


Coding directly in a wiki-environment

  • editing code would mean to have good code editing capabilities within your Wiki
  • a balance between ease-of-use and functionality would have to be found so it is on one hand not too minimalistic to be a pain to use and on the other hand it is not the reinvention of a full-featured IDE with their powerful but rather complex functions
    • How about an emacs browser mode? Full editing capabilities, although hooking the correct code formatting mode into a W3 (or whatever) form editing context may be a challenge.. =) --ebu

Compiling and testing the code in the environment

  • compiling/syntax check before beeing able to save a page sounds reasonable but could be a problem if you have to modify multiple files together to be in a consistent state again; this leaves only a simple syntax check as a criterium for Saving
  • testing the code: assuming we have something like JUnit test-cases we could run them to see whether new code actually breaks anything, if so Saving the page could be rejected
    • Have a look at fit, from WardCunningham.
      It's about writing tests that people can read.
      Example here, and here
      It looks like the ideal tool for Acceptance/Customer tests, where the customer writes tests into html pages, execute and see the result with his browser (green is good, red is bad).
      Having it integrated into a wiki would make writing the tests even simpler. -- AlainRavet
  • testing requires executing the (untrusted) code on the server with all security problems this causes; rights of new code would have to be restricted, but the more you do that the further away from a general purpose coding-environment you get

Other issues/functions needed:#

  • what about debugging?
  • assigning a label to many files to mark certain releases

Considering this, I think it would be more promising to try finding a good way to integrate other content than WikiMarkup, but without trying to be a programming-environment (of course this is hardly a vision but rather a revision control system with a discussion function).

-- Torsten 2002-12-30

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-15) was last changed on 12-Nov-2006 04:40 by