Hacker News new | past | comments | ask | show | jobs | submit login
Let's Crowd-Write a GitHub Novel (github.com/why-el)
47 points by why-el on May 11, 2015 | hide | past | favorite | 44 comments



It does seem like an interesting experiment, but after browsing a few random commits - and personally, any group project needs an initial structure for it to work. I can't remember right now but I have a faint memory of the subject somewhere, probably in college.

I would go over to http://creativecommons.org/choose/ and pick the least restrictive license or which ever works for the group / project.

You could integrate it with gitbook as fendent mentioned (I have no experience with gitbook past the homepage), or leanpub. I personally use leanpub which integrates nicely with github and the royalty fee is sweeter when compared - despite whether it will be the goal of the group or not. Or the funds can be donated, whatever gets the group motivated or is in line with the group. However, you do need to provide some sort of direction to the group. But as you mentioned, if it's just an experiment (the replies here are in itself data) go for it.

If you do decide to give it structure, you can take a look at a very basic book I set up a while back.

https://github.com/teichopsia-/valse_of_silence There are others out there that are better but I don't know of any.


Novels written by groups are generally unreadable. This is because they have no focus, and because the immediate cheap laugh always wins. It's a shame, because with a little more forethought, such shortcomings could be fixed. Ie: start by communally developing an outline, main characters, etc. It would also be interesting to use Mechanical Turk in a systemic way to have "the crowd" determine which of several proposed plot-points is most consistent with the whole, etc.


As someone who tried to run such a service years ago, I mostly agree. Even the very best stories written through this method were troublingly self-inconsistent. On the other hand, they were often hilarious a well. We published a few anthologies of short stories written with this method here: http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dap...

The experience for writers was surprisingly rewarding, but the end result was not for mass consumption. Still, as a writing tool, it showed great value.


Experiments like this either fundamentally don't understand what it is about a novel that makes it wonderful or do it for the (excuse me) novelty of it.

A novel that works on any sort of level does so by means of compelling, empathetic characters, relatable tones, great storytelling, and rich language. Crowdsourcing fails to be more effective than a single author at all of these elements.


You do realize this is in nowhere pretending to be near as effective as a novel written even by the most okayish of writers right?


There's a platform for pretty much just this thing https://www.gitbook.com/


Seconded. They also allow you to connect the gitbook account to GitHub, and version the book on your own repositories.


I wonder if it's possible to create a streamlined platform for this kind of work. Like others mentioned being able to start at an outline stage and then move on to fleshing the parts out would be interesting. I could see the outline being its own repo and each "unit"(probably chapters) get their own repo and maintainer. Nightly builds could be conducted to merge the work in the repos into a coherent whole, reconciling missing parts with their outline bullet points. An interface over the "build" to make quick commits and PRs would be nice too.

Additionally a community style guide and "story bible" would probably be in order. I believe a lot of writing projects which involve a large number of writers like video games and TV series do things like this. On an unrelated note, are there any tools to enforce natural language writing style compliance? Like code linters for human text?


It kinda depends on what you mean, but GNU Style and Diction [0] come to mind.

[0]: http://www.gnu.org/software/diction/


Is the merge step really necessary? Let people create their own branches from whatever starting point they like best, and let all branches/versions co-exist. It's not a piece of software you're developing after all; there may be many different viable paths, and darwinism can take care of selecting the winners via attrition of paths. I realize things can get fairly chaotic. The number of forks or sub-branches of a given version can act as a good crowd-sourced indication of popular snapshots.

Disclaimer: we've been toying with this idea for a while, and here's a paper (and tool) that came out of it: http://onlinelibrary.wiley.com/doi/10.1002/cpe.3420/abstract


I actually built exactly this into a web app, and tested it with a few dozen authors from a local writing club. Writers could add/branch the book at the paragraph level. Readers could open up the book at the beginning or at any arbitrary node, and there was some magic that would automatically pick the longest and/or most interesting branch to "fill" the book as you read. Readers could of course also browse any other branch. This was surprisingly easy to build with Neo4j as the data store.

I never did anything more with it because it was obviously at its best with a small number of users, who all happened to be meeting in person regularly; I had no ideas about how to scale up that experience to the wider net. Still, it was a ton of fun while it lasted.


That's really cool! I think one way to make the experiment scalable is to add a social network overlay, where people can "follow" those other authors they're watching, so they can build off their contributions.

We've been using these ideas in the classroom as well: post an assignment where multiple solutions are possible, and let students build off each other's contributions (implemented as a Moodle plugin). I want to expand this into note-taking and wikis in MOOCs.


Oh wow, this is very cool.


Subreddit for the discussion of this project: http://www.reddit.com/r/GitHubNovel/


Going to be difficult to manage everyone appending text to the same place! Every PR will be a merge conflict.


Merge conflicts only happen when the commits happen on the same line, presumably a novel is larger than a line. So there shouldn't be a problem after a while.

Maybe you were making a joke... actually you were probably making a joke.

You were making a joke. Sorry.


Not a joke. People will be appending text to the end of the file constantly. Git usually conflicts when two people modify the end of a file. Merging one PR will invalidate every other PR.

Edit: even the very first two pull requests conflicted. https://github.com/why-el/crowd-written-novel/pull/2 "This pull request contains merge conflicts that must be resolved."

Probably a critical flaw in this project.


Might be a bit early to tell how that's going to play out. Personally I wouldn't expect concatenations to be the majority of work, but more fill in the blanks and fleshing out of details.

That's just my guess though.

edit response: It's just starting out! There's only one sentence! This is not confirmation of your statement.


The first five pull requests have been text additions and 4/5 have conflicted looks like.

I don't know why you assume more people would edit a novel than write to it.


Editing's going to be a nightmare...


What would be your suggestion to improve it?


You could break up the files into lots of chapters, but then if someone wants to inject a chapter they'd have to rename the one after it. I don't see a good solution. It's a limitation of git, or any VCS really. How would any VCS know how to handle two different appends to the end of a file? All changes are dependent on the previous change, which means PRs can only be written in serial. Fundamentally version control is a bad choice for this type of project. It would be better as a website or something that put you in a queue for additions. This project looks like it will be unmaintainable.


Or just add [End of file, don't write below this line] or [The end] at the bottom.


I maaassiiivly disagree with this. The larger the project gets the easier individual edits will be. I'm a pessimist by nature but this is going too far.


can... someone explain what is going on here?

projects do suffer less merge conflicts the larger they are, and stevebmark is literally declaring this project as a whole unmaintainable from the word go, and his proof is that the story started with one line, and the pull requests to get the story off the ground are conflicting.

I don't understand what's going on here, I don't understand how anyone can support this position. This is crazy! I am very confused!


In the wrong hands, crowd-sourced writing can be used as a tool for great evil: https://web.archive.org/web/20141006094052/http://www.totali...


Haha, What an approachable idea. Might as well fire off some pull requests and have them get rejected.


I built a blog on wordpress which contained a story written by 6 writers. It turned out very well actually (Check the story section http://viehebdomadaires.com/blog/). I had to do this by adding a new writer as editor on the blog every week. It was more challenging but having something like this would be great.

There were some rules for the writers:

Each writer who follows the first writer, will have the opportunity to take the story forward during their week. They can work with the characters already introduced in the story and have the option of creating up to 2 new characters. These extensions to the story would have to be under a maximum of 1000 words.



Hello HN, this is the author. The repo needs structure and some organization, which I specifically said I forwent during my initial launch as an experiment to see what structure will emerge by simple PR merging, and if too many git conflicts, what structure could get us out of that. If git is all too cumbersome for it, then we'll learn something.

I am also in Europe and it's so late, so I will snooze for a few hours.


All seven open PRs have merge conflicts. This is just a very public lesson about knowing your tools before starting projects :) A wiki might be a better medium for this type of project.


I was completely aware of the issue and I chose specifically to let it happen (As was very clear from the README). This is an exercise in how the community can bend the nature of Git to serve a nice purpose. Absolutely no issues if this fails, in fact I'd learn more if it fails then I would if it succeeds.


Didn't Tim Ferriss edit one of his books through a wiki?


I have been thinking about developing a platform for such a thing. What are your thoughts on how it should look like? What would be useful as an MVP?


Perhaps you should have a "Trie of stories" (https://en.wikipedia.org/wiki/Trie). Every possible sequence of letters, and thus every story, is simply a path down this trie, where each node has children containing the letters of the alphabet and punctuation. Users could mark down notable places on the trie where there is a story.


That reminds me of Borges' story, The Library of Babel. It concerns a library which contains every possible book. Many great books would be contained within, but it would be impossible to differentiate them from books that devolve into pure noise halfway through.

http://hyperdiscordia.crywalt.com/library_of_babel.html


What is the ideal timeframe till completion? Who decides what gets merged? What is the target length? What is the preferred contribution size?


Timeframe, I have no idea. For merging, I'd go with consensus unless it starts to bikeshed, then I'll BDFL it.


Just submitted a small pull request as an encouragement. It would be interesting to see how it turns out to be. Good luck!


Just a suggestion: Poetica might be a better platform for this. https://poetica.com/


Christ, this is why all those stereotypes of Silicon Valley exist.


Stereotypes such as?


Such as trying to apply popular technologies to everything (in the best case, because of shortsightedness and in the worst case because you have a financial interest in the popular technology and its adoption for everything) instead of realizing that, in many cases, while you are holding a hammer, not everything is a nail.

Not making any comment about the submitted link, but I understand where that feeling comes from.


I think we broke him.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: