Mark Bernstein was recently interviewed by Exprima Media, and a good portion of what he talked about concerned Twine. If you're not familiar with Mark, he's the chief scientist at Eastgate Systems, which publishes hypertext works-- and more relevant to the discussion at hand, Storyspace, a hypertext authoring tool that was created in the 80s. Among his remarks was this:
Twine has no model for building a literary economy.
You can imagine I have some things to say about this, but allow me to digress briefly to address a misconception that has bothered me for some time, on the subject of guard fields. Mark also said:
It’s not clear that Twine’s design fully appreciates the crucial role that Storyspace guard fields play in structuring large hypertext narrative.
I've never actually used Storyspace, only read works produced with it, but there seem to be ample explanations available online of what its guard fields are about. If I understand properly, a guard field puts conditional logic on whether a reader can visit a node (what Twine calls a passage).
To which I'd like to retort: of course Twine is capable of guard field functionality. Let me direct you to the <<<if $hasKey and $searchedRoom>>[[Open the hidden door]]<<endif>>), but you can also design passages whose contents change based on previous actions the reader has taken.
I hope this doesn't seem as though I'm quibbling. It's just that this is not the first time I've seen someone suggest Twine couldn't do guard fields.
Now, as to whether Twine encourages or discourages a literary economy-- it's a slightly odd idea to me. Did typewriters encourage a literary economy? How about pencils?
I see two aspects of Twine that intersect with the notion of an economy, at least the sort of economy that conducts its business with dollars: first, that it's open source and thus doesn't require you to spend money to use it, and second, it produces HTML-formatted work that is easy to share and is difficult to sell. Perhaps if I had put a price tag on Twine, it would have encouraged people to try to sell their work to recoup their initial investment. More likely, it would have relegated Twine to a tiny userbase.
But the real reason that I made Twine open source is that I believe that creative tools should be as accessible as possible. I remember being a high school student and wishing I could get my hands on a copy of Macromind Director, for example. I wanted to make games like Myst. But how could I have possibly convinced my parents to lay down hundreds of dollars so I could maybe produce something interesting? I certainly wouldn't have been able to sell my work.
In a more enlightened/affluent time, perhaps my school system would have done the purchasing for me, or perhaps even my public library would have had a copy available to use. Instead, I downloaded Inform 5. A year or two later, when I mentioned my Director-lust to a sympathetic online acquaintance, he mailed me (mailed me! can you imagine?) burned CD-ROMs of Director along with a serial number Sharpie'd on their surface. I never installed them.
I understand that complicated tools take time to produce and that the people who work on them deserve to be paid for that time. I respect that decision, and I hope they'll respect mine.
The decision to output HTML was purely technical at the start of things. Twine was based on TiddlyWiki, which lives and breathes HTML. I think it's technical suicide to output any other format, regardless. HTML is our lingua franca, and I think it's the file format capable of hypertext most likely to be readable five hundred years after I die. I worry about these things, and so should you.
Is it hard to sell HTML files? Certainly. And yet people do. Zoe Quinn will soon be selling Depression Quest on Steam. Anna Anthropy sells a very very VERY scary house on Gumroad. To me, this is no more difficult than selling a PDF, a file format people are not often in the habit of purchasing. But it happens -- witness dndclassics.com or the Nielsen Norman Group's reports. (I wonder what it says about me that those are the two examples that spring to mind.)
The alternative, I suppose, is to output binary code, whether a desktop app or a mobile one. People expect to pay money for code, even if it's just a thin veneer over content. I have no problem at all with anyone doing that with Twine stories. I don't know much about how to do these things, but I would accept a pull request for Twine to add that functionality. Would I even be okay with someone building a tool to do this and charging money for it? Yes.
I think there's always room for open source and commercial interests to intermingle. I did this with Zoetrope; anybody is free to use the library if they like, but I sell the creative work I made with it. I see no contradiction in this.