So, I finished chapter eight of the novella last night. This means I have two more to go, and I’m on target for 30-32k words.

Chapter Eight let us check in with most of the major characters (and I think upon revision I’ll work a couple more characters into one scene), surrounding a rather major event in the story. The scenes were among the shortest in the book, and it required a lot of mental jumping around. I think in total

Chapter Nine, is the opposite: it’s basically one long narrative section that builds up to the ending. And then Ten is all bang.

(tycho goes off and thinks for a while…)

Actually, I’m thinking that I might, after all this talk, mash chapter 9 and 10 into one chapter (9), and wrap the story up in one longer chapter. I think I can accomplish what I wanted to accomplish in chapter nine in a short scene, and I think that’ll make it end on a better note. I’ve been weaving two major plot lines together and one of those lines mostly wrapped up in 8, I think I need to just push and get it done. I think the New Chapter Nine will be longer than the other chapters, so this might not effect the end length much, but frankly a little shorter isn’t a problem.

We’ll see. I think that I’m going to make some notes in the notebook, but other than that I’m going to devote the rest of my night, and possibly the rest of the weekend to other projects that need my attention.

“Write on, with confidence and hope, through all crises,” (With apologies to Elizabeth)

So I wrote this down over the course of the day in my notebook--probably as a result of some blinding inspiration--in an effort to work on the planning of the details of the the story. It makes sense in context, and while it’s about the end of the book, I don’t think it would give anything away to post it here, so here we go:

When they fix it they keep the rubber chicken but if it fucked with, say the water, the people in the future.

Welcome to living in my head.

I was listening today, as I am wont to do to an old addition of the Boing Boing Boing, a podcast from the editors of Boing Boing. It’s good stuff, and even though it’s not relevant to the news of the day, I usually don’t care. So the guy they were talking to, wrote a book on the 1854 Cholera Epidemic, which is interesting, but his previous work is on dynamic systems theory--more or less.

So here’s the interesting thing. In systems work on cities, the sort of “cutting edge” as it were is analyzing the bottom up stuff--neighborhoods, informal communities that build around places like playgrounds, schools, and market places, and other contact¹ interactions--rather than top down stuff like governments and cultural factors. (Sorry about that sentence folks!)

In cognitive psychology, the more cutting edge models, the ones that probably do the best to explain psychological reality are the top-down ones. They’re epistemologically difficult because it’s hard to isolate variables in top-down systems, but the bottom up systems don’t tend to scale well², and don’t mirror some key experiences. Clearly both have to work at the same time (and most cognitive systems include a black box, to be fair) so there’s a lot left to be discovered.

I guess what this post is all about is the fact that I never really thought to take cognitive-style systems theory out of the mind, nor did I think that when I did, the “radical” positions would be reversed. Part of the issue is that psychology has always been a very bottom-up field, Wundt was a bottom uper and Skinner was the very picture of a bottom-upper.³

The key part of the distinction between top-down and bottom-up is what you take for the unit in the system, of course. Chunks of information in your mind, is way different that a person in a city, or a city block on the city, or an IRC channel online.

Anyway. That’s what I’ve been crunching through. Hope you’re interested.

Longtime friends will know that I have these two blue-green tea mugs--actually there have been 4 in total, though only three survive today; and I only ever really have two at any given moment--and they are sort of like character objects, because I had them with me pretty much all day every day. The thing that got my friends I think most riled up about them, is I didn’t wash them, on the principal that a) tea is acidic and therefore naturally a bit antiseptic, but more importantly that I make tea by pouring boiling water on it. While I wouldn’t want to perform surgery in a tea cup in this state--but then, find me a dish that you would like to do surgery on, I dare you!--given the myriad of problems with kitchen sanitation (ew, spunges) I thought I was in pretty good shape.

Well since I’ve been unemployed, and taking classes in an non-friendzied way, I’ve developed a slightly different caffeine habit. When I go out, I rarely take both mugs with me. I found I wasn’t ever drinking both of them when they were still warm. Whereas, I almost always finished both of them before the end of an hour class when I was AlmaMater. Instead, I’ve taken to making a three-cup pot, most days when I’m at home and drinking from a stoneware handmade coffee cup that my dad brought home. On peak days, we’re talking about 4-6 cups of tea, but usually more like 3, in general, which I think is about par for me, maybe down a little, but not much. Lest you think the habit is waning.

Even if I’m consuming about the same amount of tea as I always did, my aforementioned travelmugs are getting much less use. I take one of them out of the house about 3-4 days a week, When I’m home, they don’t get used. The thing about my above sanitation plan, is that it depends on regular use, and recently the cups haven’t been getting regular use.

So I decided--you’d be proud of me--to put the cups through the wash, because they’d been sitting for too long.

End result?

The paint melted off in the dishwasher. Which means:

I’m looking for new cups.

I’d just like to say to all of my former roommates, who gave me shit about the not washing the cups:

I hate you all.

I’ve written here about my email woes. The 500 megs of archives in plain text format? You know the drill.

I’ve always been a desktop email client kind of guy. I’ve used versions 1 and 2 of Apple’s Mail.app, and before that I used Outlook when I was a PC user. I like being able to deal with my email when I’m off-line.

For a long time recently, I’ve been working on streamlining all of my digital things. Fewer pieces, less pack-rat tendencies, better backup, more command-line things, less fuss.

While Mail.app is pretty cool, all things considered, I feel like it could be a bit better. For starters, it’s database access is needlessly slow and pokey. Secondly, the procedure needed to change the originating email address is really convoluted, and defeates the nifty “sort by incoming” email address feature that is perhaps Mail.apps strongest feature.

So I downloaded Pine the other day, and while I haven’t gotten set up into it (mostly because I don’t want to have multiple places checking the same pop account, and would rather wait till I was able to switch to IMAP) I think it’s pretty cool.

I do realize that this makes me a really HUGE dweeb.

Other thing for the dweep files. I now have a “google” command line script which makes it even easier and faster to do the google. Sigh.

I posted earlier today, a copy of the last installment of the Open Source Knitting. It answers some of the preliminary “how” questions that I think the rest of the series avoided.

Click here to read more about Open Source Knitting Technology

While I think the project is still very much “alive,” and holds a place in my mind/mental energy, I think it also is something that I want to do right, and I’m going to wait till I have time time and some more of the planning worked out right. I think a huge part of this, interestingly enough depends on having the community at Ravelry be sufficiently large and open to all. I say ravlery because it is centralized and it is not niche, not because of any particular dependency there. I also need to be a little bit better about being on IRC I think…

Anyway, back to the grindstone.

When I started this little “series” on open-source knitting, I said that it had a lot of connections to other projects and ideas that I’ve worked with with relation to Station Keeping and the hypertext/writing posts, and this post--which address technological (ie. file systems) organizational concerns and collaborative organization--I think dovetails nicely with the more “general interest” aspects of this series. Additionally, when I started the series, I set out a number of goals that I hoped to address as part of this series. This essay addresses the last of these goals, the “Technological methods of attending to such a(n open knitting) project.” The total list of goals is:

• Is there a layer of information that goes into knitting design and documentation that isn’t typically exposed in “closed”/conventional publications? (that would be equivalent in role to source code)?
• The role of editors and communities and the sometimes very “conventional” development models that “open” projects use.
• The way GPL/GFDL knitting projects can be used commercially.
• Technological methods of attending to such a project.

One of the biggest challenges that I think faces new collaborative projects, is that when you’re planning it out you say “we need to end up with a project that accomplishes x, y and z,” and you spend all your time/energy building toward your end goal, and forget the smaller things that have to be in place first. If you’re writing a book, and you spend all of your initial planning time organizing how the historical forces that produce the climax line up, and then you sit down to write and your characters aren’t really fleshed out, and you end up with a hundred pages of exposition that no one wants to read, or the feeling that you have to do even more planning, despite the fact that you have thousands of words of notes written out. Now this works out when it’s just you writing the book, because you can toss out the hundred pages once you know your characters and write a real beginning, but in a collaborative project (of any sort I suspect), if your initial work is too focused on the work that will happen a year hence, and not focused on what will happen now, even if people are wild about contributing to the project, they won’t have a clue about how to participate, and the project will almost certainly flop.

It seems that the initial planning of a project should avoid setting up a firm structure for the entire life of a project, but rather strive to set up a firm basis and framework that would allow the project to develop on its own particularly in the beginning. In the book example above, spend time developing where your your are at the beginning of the story, know something about where they are, and also know where they’re going, but let the little details fall into place later. In a software situation, make sure that you have a database structure that you can live with before you start designing the interface in ernest. In a sweater, know your gage, yarn and intended size before you start stressing out over how to incorporate the shaping into the measurement. There are of course exceptions to these rules, and really great ways to break the rules, but when you’re working in a group situation, unless all your developers are working from the same page, it’s really difficult to maintain energy and keep things all together.

So lets try and import these ideas into a discussion of what an (but clearly, not the only,) open source knitting project would look like:

• A single OSK project shouldn’t try and collect everything about knitting, for starters this pushes us back to an encyclopedia model, and I don’t think that’s what we need. Particularly in knitting, there’s too much variation and you’d spend as much time deciding on “canonical” versions and not enough time enjoying the diversity. Furthermore, I think there are probably too many different kinds that it could work as a single coherent project.
• Avoid talking about techniques too much: While most knitters mostly knit the same way, there’s a lot of difference of opinion in terms of how to accomplish various kinds of knitting operations. While there probably is a need for a collection of these kinds of techniques, and I think Elizabeth Zimmerman made a great argument for the idea that while knitters are always developing new techniques (and should receive credit for this development,) the techniques themselves are probably always already in the public domain because given knitting’s history it is hard to imagine that we are the first to “invent” something (hence Elizabeth’s use of “unvention.") What’s more, with resources like Mary Thomas' Book of Knitting techniques, or Montse Stanley’s Knitter’s Handbook and the Schoolhouse Press Glossory that there isn’t a lot of room for improvement, beyond a collection of contributions. In other words, since open source succeeds at combining energy and efforts of a lot of people, the projects need to be ones where multiple perspectives and abilities would create a better gestalt. A technique handbook, in contrast might benefit from many perspectives, but probably wouldn’t benefit from any sort of group process.
• An OSK project should track version development: In the software world version tracking systems are used to make sure that changes in code are tracked as the project progresses, so that changes can always be reversed if the “old way” works better than the new way. Also this kind of software allows you to create “branches” so that you can work on bleeding edge feature/content development (so called “nightly builds”), and “release polishing” so that your finished projects are clean, clear and functional. In writing terms, this means that you can edit/polish the text without impinging upon your drafting. Which is incredibly helpful when working in a group setting. Versioning systems are also very atomic and keep track of differences (diffs), and work to keep track of and organize the most recent version of every file, even if more than one person is editing it.
• An OSK project should create and foster community development: This is perhaps a bit too obvious; however, I think it should also be said that community needs to have a space that’s separate from the project (make it possible for people to talk, outside of the actual project files.) Taking wikipedia as an example, while wikipedians can talk on the “talk/discussion pages,” it’s my perception that most of wikipedia’s community happens on IRC channels. While its not “a part” of wikipedia in the conventional way, I’m sure that wikipedia depends on those IRC channels to keep the community functioning.
• Separate workspace with display space: I think this point is part of my larger objection to using an idealized wiki model for development, where the entire website that the “public” (casual user) sees is the same as what the “core” (developers) are working on. This means that the “product,” is always rough and incomplete, and I think in an odd way it pushes developers to work on larger rather than small parts of the project¹. Ideally, I think these sorts of projects would work better when you have ten developers contributing one part each to ten projects, rather than ten developers contributing one whole project, or something along those lines.

I also had an organizational tree that I was going to seek some feedback on, but I think that’s safe to live in the notebook for a while longer. I think it’s clear by now, if any of you are still with me, that I’m planning on doing something with this project, but I think there’s more to develop, clearly, so while I think I’m mostly done milling over and presenting the theory, there’s plenty of work left to be done on developing and establishing such a project, so if any of you are interested in this idea, of an Open Source-Knitting project, I’d really like to hear from you.

Cheers, tycho

Found via Merlin Mann, this hysterical video of what life would be like if it worked the way that YouTube comment threads work.

I know it’s been a slow weekend. I’ll be posting more soon, don’t worry.