+1 on "The Future Does Not Compute". One of my favorite books on this topic; IMHO it didn't get enough notice when it was new -- would be nice to see it get some now.
And Chris Daw, if you're out there: I still have your copy! I bought my own long ago; I've been trying to track you down ever since to return yours.
I use SVN daily too. Sometimes SVN is the right tool for the job, sometimes Git is.
They fixed it fast! (I'd delete the original comment now if I could.)
Odd typo (or transcript-o) -- the word "privatizations" should be "prioritizations" in this sentence:
"Given the huge topic space the authors had to choose from, their privatizations [should be 'priorizations'] are intelligently made and obviously reflective of long experience using Git."
I don't know how that happened. It was "prioritizations" in my submission at http://slashdot.org/submission/2368485/book-review-version-control-with-git-2nd-edition .
It is not possible to compete with Git on its own terms without being open source. Being zero-charge for small teams is not going to cut it, IMHO.
Nope, no coordination nor conspiracy.
I reviewed the book at my own schedule, and as far as I know O'Reilly Media planned their Cyber Monday without any connection to when this review would be posted. Slashdot didn't promise me a posting schedule anyway, although a few days ago an editor wrote to say he'd probably run it on Monday. I forwarded that fact to a couple of people at O'Reilly (see below), but that was on Thursday, which was the Thanksgiving holiday in the U.S. Suffice it to say it is highly doubtful that O'Reilly Media planned their whole Cyber Monday thing starting a mere three days before the event and over a long holiday weekend!
However, I should have added a couple of disclaimers to the review:
O'Reilly sent me the copy to review, and, more importantly, the editor on the book, Andy Oram, is also my editor. The free review copy is not really worth a disclaimer, though; I'm just trying to be thorough. First of all, the amount of time it takes to read a book and write a review far outweighs the cost of purchasing a copy, and second of all, as an O'Reilly author I'm pretty sure I could have just emailed them asking for a copy anyway, regardless of whether I were reviewing it
So, this was not a slashvertisement -- just a coincidence, to the best of my knowledge.
That's a good point about the rewards, but note that non-profits have been using the "increasing rewards for increasing donations" system forever. It *long* predates Kickstarter and even the Internet. Think of donating to your local public radio station: give $10 and you get a thank-you card; give $50 and you get a tote bag too; give $100 and you get a tote bag plus discounts at cooperating restaurants and shops all over town; give $1000 and you get all of the above plus your name read live on the air plus maybe more. It's just fundraising 101.
While you're right that it's an important characteristic of Kickstarter, it's not a particularly defining one, because most serious fundraising operations are doing it already. Whereas the Threshold Pledge system, while not unique to Kickstarter, is much less widespread in fundraising in general.
I hope the FSF, or (say) the Software Freedom Conservancy, adds it as a feature, because I'd love to be supporting free software projects through organizations like them using Threshold Pledge.
Hackable medical devices are a known problem -- there's a great paper on it from Karen Sandler, at that time at the Software Freedom Law Center (she's given OSCON talks about it too):
And the SFLC's announcement / summary of the paper:
This is not the Kickstarter model. It's just accepting directed donations toward a project (and MediaGoblin is certainly a fine cause!).
The Kickstarter model is the "Threshold Pledge" system (http://en.wikipedia.org/wiki/Threshold_pledge_system). It means you set a threshold, a minimum fundraising goal, and all the funders pledge amounts toward that goal. Until the goal is reached, the pledges are either not called in, or are held in escrow to be returned in the event the goal is not reached. That way, everyone who gives money knows that, if their money reaches the recipient, then the recipient got enough to actually accomplish what it is trying to do. If the recipient doesn't get enough pledged to reach the goal, then no one loses their money.
It is designed to solve the problem of "I'd love to donate to X, but only if I know that enough other people will donate for X to be sustainable / achievable / whatever." In economics, it's called an "assurance contract".
What the FSF is doing here is not the threshold pledge system. It's just accepting directed donations.
Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker