Purpose: we combine our love for coding with our love for xkcd, for shared fun.
Home page: http://the-xkcd-community.github.com/th ... r-project/
IRC channel: #redspider at foonetic.net
Issue tracker: https://github.com/the-xkcd-community/t ... ect/issues
Wiki: https://github.com/the-xkcd-community/t ... oject/wiki
GitHub repository with Readme: https://github.com/the-xkcd-community/t ... er-project
Any questions: ask here or have a look at GitHub to get an idea of the common practices.
The remainder of this post shows how it all started.
___________________________________________________________
Edit 2: it's not just an "idea" anymore, so I've updated the thread title to only show the name of the project. It used to be "Idea for a fun joint effort: red spider project".
Edit: the working title was "xkcd hacking project" but we've settled on the name "red spider project".
"xkcd hacking project" is perhaps a bit of a vague description. I'll just describe what I envision. It's a bit lengthy because I'm trying to provide a more or less complete plan, but everything is open to change. Please discuss if you're interested. I'd say that if the thread gets 10 replies, we can assume that there's enough interest and we should just start off with whatever seems to be the consensus at that point.
THE GOAL
- To have an enjoyable time collaborating with fellow xkcdians on an ongoing coding project.
- To write code that is interesting or amusing for others to read, or both.
- To write programs that give you a fuzzy "xkcd feeling" when used, because they produce amusing, interesting or touching output (or a combination).
- To make a cozy, messy web of programs that may sometimes call other programs, possibly in unanticipated ways.
- To go crazy.
THE MEANS
- A publicly hosted repository that people can easily get write access to. For example on GitHub.
- A permissive license that applies to all parts of the project. Perhaps a variant of the MIT license with some alternative formulations to make it more xkcd-like.
- Platform neutrality: terminal only, programs interoperate with exit statuses, pipes and file redirection. This is kind of unixy but it works fine on Windows as long as you keep it simple.
- Many small though not necessarily independent programs, rather than one monolithic thing. This makes it easier for people with little time or short attention spans to join in, while still allowing for collaboration.
- All (free of charge) programming languages are welcome and encouraged. The more diverse the better.
- An open-minded attitude: all ideas are interesting. There are no limits on what a program may do, except that it must not be malware.
- A more-or-less fixed, simple directory structure so things can be found and automated.
- A common build system so all compiled stuff can be installed in one go, for example with CMake.
DETAILS
Name: please suggest something better than "xkcd hacking project".
Root directory contents (please mentally translate forward slashes to backward slashes if that comforts you):
- bin/: installed commands. No subdirectories.
- lib/: installed run-time and link-time dependencies of the commands. Not just binaries, e.g. also Python objects or awk filters that are meant to be used by a shell script. No subdirectories.
- build/: anything produced by the makefiles that is not supposed to go into bin/ or lib/. Assuming that we use CMake, this includes platform-specific makefiles generated from the CMakeFiles. Subdirectories depend on the whims of the build tool.
- include/: all source files that are meant to be included/imported in other source files. No subdirectories.
- src/: all other source files as well as the makefiles of individual programs. For many small programs written in a scripting language, "installing" it will be nothing more than copying it from src/ to bin/. Subdirectories are avoided unless a single program uses lots of source files. Reason: this encourages people to read code from others and forces them to avoid name clashes.
- doc/: if anyone feels an urge to write proper documentation, they can put it here. HTML and plaintext are preferred. Subdirectories if the documentation to a given command consists of more than one file.
- config/: optional configuration files for the user. Only sensible if we write commands that make use of configuration files. No subdirectories.
- work/: any other user files, possibly generated by the commands in bin/. Subdirectories at will.
- A "master" makefile that builds and installs everything. Exception: programs that require payware or that aren't portable between Windows and unixy systems. "make clean" (or whatever that command is going to look like) erases everything from bin/, lib/ and build/.
- A .gitignore file (or the functional equivalent if we use a VCS other than git). Everything that is not in src/, include/, doc/ or directly in the root directory should be ignored by the VCS.
- License.txt: the xkcd-ified MIT license (or whatever we're going to use as the default license). Source files that are native to the xkcd hacking project should refer to this file.
- Readme.txt: how to install, how to use, how to hack, any caveats with regard to the license (e.g. if we happen to copy LGPL'ed libraries), etcetera.
- Dependencies.txt: list of all third-party software that one needs to have installed in order to be able to run the master makefile and the commands that are installed by it. With pointers so people don't need to search everything on the internet first. Optionally also a list of payware/platform-specific software that will enable more commands.
- Things that I forgot about.
Collaboration:
Anarchy is fine. If you seek a partner (or multiple) for some program, or if you want to ask/announce something to everyone in the project, use this thread.
The first command:
I think a command that puts some useful environment variables into place would be most convenient. For example by prepending bin/ to PATH and include/ to CPPPATH. Perhaps it should also automatically set the working directory to the xkcd hacking project root and display a random xkcd comic. I propose to call this command "xkcd".
I think somebody has to claim the initial version of this command. Once the initial version is there everyone can modify it as they see fit.
Platform neutrality:
Most programming languages allow you to write platform-neutral code (especially in small programs). This is also true of several build tools, such as CMake, SCons and Perforce Jam. The notable exception are shell scripts. That's kind of unfortunate because those are exactly the things we'll most likely want to use to compose small programs into larger ones. We don't want to force Windows users to install MinGW or Cygwin.
Possible solution 1: we write a simple "shell script compiler" that takes a shell script from any supported language (at least POSIX sh and Windows cmd) and translates it to the current platform, if necessary and supported. The makefile of a shell script calls this compiler. In order to keep this feasible only the most basic functionality should be used, i.e. variable assignment, variable evaluation, platform-neutral command calls, command grouping, piping, file redirection, if-else and loops. If you want functions write separate shell scripts instead. If-else and while conditions should only check for exit statuses. Anything else that you might normally do with a shell script should be deferred to commands from within the xkcd hacking project.
Possible solution 2: if you write a shell script, you have to implement it at least in the POSIX sh and Windows cmd languages. The makefile of the shell script will choose the one that is appropriate for the current platform and copy it to bin/.
More possible solutions: possibilities 1 and 2 can exist alongside. There are probably also other possibilities that I'm unaware of. Something like a free cross-platform shell would be ideal.
External tools:
Should be free of charge, available for at least Windows and unixy systems and kept to a minimum. Except for the last requirement this also applies to programming languages, so if you want to use something like MATLAB or Mathematica please try to write it such that it can be run by a free ripoff, e.g. Octave or Sage.
Non-standard or platform specific libraries:
Should be avoided as much as possible. Small, platform-independent libraries can be copied to the xkcd hacking project code base if the license permits it.
Repository:
We have to agree on some "sacred" integration branch that will contain and receive only stable code, so people can checkout that branch if they just want to use some programs from the project. I guess coders should be allowed to do whatever they want in any other branch.
I don't care who creates it. If you're faster than me, go ahead. But please announce it here.
