“Just write,” they said, “It doesn’t matter what tool you use…”
Writing is the hard part, everything else is just formatting. You could scratch your novel into a wall with a rock, or use a command line text editor, the point is: you should be focusing on writing. Your tool should be a secondary concern.
…says the README file trying to sell me on a writing tool…
Right? I’m losing the sale before the customer even drove the car, but Giterary isn’t really selling something (it happens to free, open source software, based on other, powerful, freely available tools).
So, what does Giterary do as a writing tool? Giterary is a tool that suggests a better way to work, and helps if it can, making the hard things easy, and keeping the simple stuff simple.
To demonstrate, we’ll start by asking a question: if writing is hard, or even just starting to write, how hard is it when you have a 120,000 word manuscript?
“A first novel won’t be as much work as you think. It will be much more. ”
Consider the scale of a novel. For the most part, published writing projects weigh in at around ~50,000 to 100,000 words (and often more). They can take years to write, after which they tend to require extensive editing, re-reads, re-writes, and whatever requisite iterations it takes to make a better product.
Now consider a machine with ~50,000 to 100,000 moving parts. A novel-machine that takes a human’s attention as input and outputs compelling plot, worthwhile characters, and subtlety. As the author, it’s your job to fabricate the machine parts, construct them correctly, and maybe apply a layer of paint. Sure, it works for you the first time you run it, but when your best friend takes a whirl it seizes midway past the second-stage turbine spooling. You walk slowly through the smoldering wreckage. Your friend is alright. Your pride is not.
The point is: if writing a novel is hard, maintaining a novel is complex. The latter of which is overlooked when just writing is a primary concern.
Giterary offers a set of nice things to write and maintain a novel, managing complexity at both ends of the process.
When programmers are lazy, everyone benefits.
Computer programmers look at machine with 100,000 moving parts and laugh. The software you interact with on a daily basis, whether it be on your computer, a website, your phone, or turning on your car, probably represents a few million lines of code (they don’t even count the words).
How do they deal with that kind of complexity? How do they keep all that in their head?
Well, they don’t, aside from a vague sense of how things were when they left. Instead, they write tools to do it for them, to track things, to identify things, to keep records, and to compare things. And then they automate it so they can get on with whatever is interesting that day.
They laugh. Authors should take note.
Programmers have tools to tell you if files are the same or different, and tell you what changes. The same tools can take that difference, and apply it to a similar set of files, and have the resulting files be updated to reflect the differences. They can take those differences over time and show a history of a set of files, documenting what changed, how it changed, who changed it, and when. They even added a cute “What was the programmer thinking about?” text box when a programmer makes a change. They even developed a database that lets you keep multiple versions of the same files, and associate them with everything else for when those files were correct, and everything plays nicely.
These simple but powerful tools allow not one, but hundreds of people with different ideas, styles, work methods, and work schedules to work on a single repository of information.
And they’ve had this technology for decades.