Maybe the value is that you get quickly something that others can then start improving in small steps.
I believe this kind of approach is good at solving the two main problems we usually face in projects:
1) Getting started
2) Delivering at least something
I hope their effort bears fruit. Writing textbooks is long and tedious, more so than one would expect before actually sitting down and trying it. I had hoped to help it happen with a web app I launched this year:
"Programs must be written for people to read, and only incidentally for machines to execute."
- Abelson & Sussman, SICP, preface to the first edition
We know as a fact this is not followed. Code in a hackathon is usually proof of concept for an idea, not launch ready code. Who needs a kernel/proof-of-concept math book with all the existing content out there? Do more harm than good IMO.
Big plus point for the collaboration effort though, which probably would not have happened otherwise.
Good point, however, there are no free textbooks that are made by collaborative effort. This book is also free to edit, so teachers can take parts out, add parts and so on.
This book is definitely written "for people to read". It is very clear and understandable. One could think that a text book written over one weekend is very messy and hard to read, but this was indeed not the case. The writers especially focused on making the book as easy to understand as possible.
They are writing it during this weekend, but press release for hackathon was month ago (http://pastebin.com/sKKnRL19) and if I recall correctly he was hinting something about this project month or two before that. So there has been time for planning.
And like Tuna-Fish said, Finnish high school courses are quite limited and self-contained.
Much better than what I saw at a Hackathon earlier in the week. It was Tech and Art (Dev's and artists collaborating) which was a great event. Though one project was a 'Pastebin magazine' and consisted of them finding tweeted pastebin links, putting them in Word/Indesign and printing them out.
I believe this kind of approach is good at solving the two main problems we usually face in projects: 1) Getting started 2) Delivering at least something