Welcome to project textbender. We are developing recombinant text, a new medium of collaborative design and composition.
Work is on hold. Please see http://reluk.ca/project/textbender-tasks.html.
Initial development is aimed at creative literature. But most of the software will be easily transferable to other applications, as well.
On the other hand, for those undeterred by the difficulties, early involvement offers advantages. Not least is the chance to take a leading role in the design of a new medium,1 and the creation of a new form of art. If you are interested, the place to start is the alpha demonstration. You may have glanced over it already. What we ask, though, is that you actively work in it (as far as its shortcomings allow) in order to get an artistic sense of where the medium is going — toward what possibilities? toward what pitfalls? — and then to come back, and share your insight and advice. Please see the reporting guidelines at the end of the demo.
We have no test artists yet. Some writers and poets have expressed an interest. Many are Mac users though, and textbender does not support that platform yet. (We are looking for a Mac/Java software engineer to help with that.)
Although development of the prototype toolkit is on hold, pending the design review, work can still proceed on other lines. Other opportunities remain open:
Among these various connections, graduate students might see a thesis. Professional academics might see possibilities of research and funding. If you are thinking along these lines, please join our discussion group and keep in touch.
Ensure you have Mercurial installed.
Create a new working copy from the codebase trunk:
hg clone http://reluk.ca/var/db/repo/textbender/ working-copy
This creates a directory ‘working-copy’. (You can freely rename it, or move it.)
Test build the code. (Technical writers can skip this step.)
You can then proceed to modify the code.
When you are done, ‘hg commit’ will permanently record your changes in the working copy's repository. You can then share your work, either by publishing your working copy/repo to the Web — using ‘hg serve’ or ‘hgweb.cgi’ — or by email, using ‘hg bundle’.
If you make improvements, please send your repo URI (or bundle) to the maintainer for inclusion in the next release.2
Most contributors will be acknowledged directly in the project files, either as authors or sources.
Co-authors and later contributors may append their names and extend the copyright year. For example:
Copyright 2007-2008, First Author, Second Author. Permission is hereby granted...
1. |
The prospect of design leadership for artists is based on the application's specialized utility (artists' medium, and artists' tools), and the openess of the project's structure and licence. Given these, should artists ever find that their insight or advice is being ignored, they will be free to copy the project as a whole, and go in a separate direction with it. Some of them, after all, will be engineers as well as artists. And the other engineers left behind, what choice would they have but to follow? In the end, the overall design is likely to be a collaborative effort between artists and engineers. Artists will have the most say in the design of the human interfaces (which affect them directly), and also the practical utility of the tools (features) and their performance. Engineers will have the most say in the system's infrastructure, which is largely invisible to the users, and has potential applications that extend beyond art, into other domains. But at this juncture, only the artists can lead the way forward. Development of the alpha prototype is on hold, pending their participation. They've expressed an interest, so it would be imprudent to proceed to beta without them. (We'll work on other parts of the medium, meantime.) |
2. |
Acceptance of code changes cannot be guaranteed. On the other hand, if your changes were ever to be rejected, you could easily carry on with them in complete freedom, even in collaboration with others. Each working copy of the codebase can double as a bona-fide project branch, or even a separate project. Mercurial is flexible enough, therefore, to allow work to proceed in parallel on both sides of a dispute, until the dispute is eventually resolved; either by a merger, or by a fork. Forks are not always to be discouraged. Unlike other projects, the focus is not so much on software development, but on exploring a new medium. Multiple projects will be needed to cover the ground, in different directions. Most of the map is still blank. |
Copyright 2007, Michael Allan. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Textbender Software"), to deal in the Textbender Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicence, and/or sell copies of the Textbender Software, and to permit persons to whom the Textbender Software is furnished to do so, subject to the following conditions: The preceding copyright notice and this permission notice shall be included in all copies or substantial portions of the Textbender Software. THE TEXTBENDER SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE TEXTBENDER SOFTWARE OR THE USE OR OTHER DEALINGS IN THE TEXTBENDER SOFTWARE.