-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
405 lines (228 loc) · 26.2 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Software (mostly Sakai), Education (mostly ePortfolio), Complaints (mostly unreasonable), Thoughts (mostly unintelligible) — noah</title>
<meta name="author" content="Noah Botimer">
<!-- Le HTML5 shim, for IE6-8 support of HTML elements -->
<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<!-- Le styles -->
<link href="/assets/themes/twitter/bootstrap/css/bootstrap.min.css" rel="stylesheet">
<link href="/assets/themes/twitter/css/style.css?body=1" rel="stylesheet" type="text/css" media="all">
<link href="/assets/themes/twitter/css/pygments-manni.css?body=1" rel="stylesheet" type="text/css" media="all">
<!-- Le fav and touch icons -->
<!-- Update these with your own images
<link rel="shortcut icon" href="images/favicon.ico">
<link rel="apple-touch-icon" href="images/apple-touch-icon.png">
<link rel="apple-touch-icon" sizes="72x72" href="images/apple-touch-icon-72x72.png">
<link rel="apple-touch-icon" sizes="114x114" href="images/apple-touch-icon-114x114.png">
-->
</head>
<body>
<div class="navbar">
<div class="navbar-inner">
<div class="container">
<a class="brand" href="/">noah</a>
<ul class="nav">
<li><a href="/archive.html">Archive</a></li>
<li><a href="/categories.html">Categories</a></li>
<li><a href="/tags.html">Tags</a></li>
</ul>
</div>
</div>
</div>
<div class="container">
<div class="content">
<div class="page-header">
<h1>Most recent posts</h1>
</div>
<div id="home" class="row">
<div class="span8">
<!-- iterate through the posts on this page -->
<div class="post">
<h1><a href="/posts/2010/11/04/thoughts-on-sakai-oae">Thoughts on “Sakai OAE”</a></h1>
<p class="meta">November 4, 2010</p>
<p>If you haven’t heard, there has been some rebranding effort in the Sakai community recently. The project formerly known as “Sakai 3” has been <a href='http://sakaiproject.org/news/sakai-open-academic-environment-confirmed-official-sakai-foundation-project'>dubbed</a> the <em>Sakai Open Academic Environment</em> (OAE). The reaction has been varied; some wonder why a name change at all, some don’t especially care for the choice, some wonder why it wasn’t chosen differently…</p>
<p>I’m writing this post to give my perspective of why this is a healthy community move, even if the exact name “OAE” doesn’t stick.</p>
<p>This is just one more recognition that we’re talking about a new and different product. “3” doesn’t work very well as a product identifier, amongst ourselves, or to the broader world. This is an important distinction between Sakai (the community/brand/make) and Sakai (the software/product/model).</p>
<p>As the project portfolio for the Sakai community expands, we need real names for the projects. This looks to become more natural if we draw closer to our <a href='http://www.jasig.org/'>Jasig</a> friends, who already have a number of named projects. (As a side note, be ready to have discussions on your campus and at conferences of how a Collaboration and Learning Environment [CLE] is different from the OAE.)</p>
<p>So, my takeaway, whether you like the name Open Academic Environment or not, is that this is an important step on the maturity path for our community. -NB</p>
<p><em>P.S. Although OAE doesn’t roll off my tongue very well, I’m glad to be done with this dance: well, take the S off, and change it to a three. Yeah, it’s a nerdy thing. No, I didn’t pick it. They usually pronounce it… Explaining it always felt like watching awful karaoke.</em></p>
</div>
<div class="post">
<h1><a href="/posts/2010/03/16/sakai-futures-part-2">Sakai Futures, part 2</a></h1>
<p class="meta">March 16, 2010</p>
<p>It seems that at least a couple of people read my <a href='/posts/2010/03/13/sakai-futures'>last editorial</a>. I didn’t expect to write a part 2, at least not here or now. But it’s worth a bit of clarification…</p>
<p><em>See the very end for the “bit” part…</em></p>
<p>The Sakai Product Manager, Clay Fenlason, has <a href='http://sakaiproject.org/blogs/khomotso/debates-about-community-process'>posted some notes</a> on this ongoing discussion. He rightly points out that it is evolving and happening in large part on the “management list”, and that you should join up or watch the archives if interested.</p>
<p>The purpose of this post is to clarify what looks to be a basic disconnect on my opinion, since I was cited and don’t mean what it looks like Clay heard. He says:</p>
<blockquote>
<p>But again our first practical example risks a misunderstanding - that the full process is only really about Sakai 3. There are even some knowledgeable community leaders that are <a href='http://www.dr-chuck.com/csev-blog/000709.html'>coming to this conclusion</a> and <a href='/posts/2010/03/13/sakai-futures'>holding it forth</a> as an insight.</p>
</blockquote>
<p>It seems that Clay has drawn an interpretation from my communications where I would attribute the process primarily, or even exclusively, to 3.x, thereby grandfathering 2.x into some who-knows-what process. If he read it this way, it is fair to say that others might, too.</p>
<p>I feel <em>quite the opposite</em>, in fact.</p>
<!--more-->
<p>I think it makes a lot of sense to codify and ease the ebb and flow of 2.x, and that the documented “2009 process” isn’t all that far off once we get past impressions of who’s telling whom what to do. There are some bits to figure out about roles (QA? RM? MT? PC? PM?) and how work gets done with attentions being spread but, at 10,000 feet, it seems largely representative of the problem we need to solve for 2.x: measured evolution of a mature product with regularly released versions (including 2.8, 2.9, and 2.10, IMHO).</p>
<p>I would say that it is much less clear how it applies to Sakai 3 at this point.</p>
<p>What I’ve struggled with most is “bootstrapping” Sakai 3. That is, understanding the very first step in a process that assumes projects that are folded into a product – that there is some shape, texture, and flow that must not be disrupted. Essentially all of the language is built around “the release” or “the product”, and our mental models draw from our experience to date.</p>
<p>Sakai 3, as a whole, entering the Incubation phase of such a process is perplexing to me. I’m confused as to whether we intend to refine it into a super-process or possibly change it to meet emerging needs to the disservice of existing ones.</p>
<p>It is especially perplexing because it is absolutely clear that we have <em>two familial products</em> at different generational stages (one adult and one embryonic). There is presently no product into which the “Sakai 3 project” would be folded. This is a bootstrap project for a bootstrap product – a recursive paradox that unravels the whole process unless we find the base case.</p>
<p>I suppose I might say: is it a chicken or is it an egg? When will we know and how?</p>
<p>More rhetorical questions: are we planning to have a super-release for the whole ball of wax? Are the product and release “Sakai”, or are the products and releases Sakai 2.x and 3.x?</p>
<p>In more literal terms, where do we draw a line around the first bit of work that makes up a release for Sakai 3 (not necessarily enterprise-grade)? When do we say that Sakai 3 has made it to the end of the Product Development phase? What is the first project that is decidedly not “in the core”, to be set upon an Incubation path for inclusion within that release? Who decides?</p>
<p>We should also note that there are only three really interesting values in cardinality: zero, one, and infinity. Moving from one to two is very hard precisely because it’s the first time you have to account for infinity.</p>
<p>Maybe these things don’t matter. Maybe we just need to hammer along and release some software and the rest will become obvious. I can’t argue with charging forward and putting pen to paper, so to speak. No matter what, I certainly don’t want these philosophical dronings to dissuade people from the hard work they <em>sign up to do</em>.</p>
<p>I believe in open source, plainly and wholly.</p>
<hr />
<p>Let me be clear about my ultimate point from part one:</p>
<p>The Sakai community has reached a generational moment. We are moving from one product to two. We are not moving from one community to two. We are not moving from one Foundation to two. This is bringing a pile of organizational challenges.</p>
<p>My opinion is that we need to accept this, be clear about our intentions and commitments to our 2.x adopters and friends, make room for the two streams to progress in their own natural space and time, and try to understand what a bountiful ecosystem of Sakai projects might look like. It just so happens that our httpd2 looks to be numbered 3. -NB</p>
</div>
<div class="post">
<h1><a href="/posts/2010/03/13/sakai-futures">Sakai Futures</a></h1>
<p class="meta">March 13, 2010</p>
<p>Something has been gnawing at me. Here is my initial assessment:</p>
<p>There are some gradual but quite significant changes coming to how the Sakai community works and releases software, and these changes are quite unclear.</p>
<p>I don’t think this is controversial or surprising. I do think that there are lots of ideas, fears, and desires for how this might work out. We are definitely having organizational growing pains.</p>
<p>Here is what I see as already present:</p>
<ul>
<li>Two new groups: the Product Council and Maintenance Team</li>
<li>Release Management emerging as possibly distinct from QA</li>
<li>A relatively new and evolving Product Manager role</li>
<li>Two streams of software (2.x and 3.x)</li>
<li>Tension about how each of these roles shapes either stream</li>
</ul>
<p>Where I’m going with this is that three of us on the PC share a homework item of looking at what would be helpful support of our Incubation and Product Development phases. However, I have been confounded about the very essence of this assignment given the above list. See the email below for specifics – it also frames this post as a written reflection.</p>
<p>So, let me reflect.</p>
<!--more-->
<p>It has long been obvious to me that “Sakai” has no simple definition. I posted this to the user list in Jan ‘08:</p>
<blockquote>
<p>I suppose I’m also trying to mention that “Sakai” is at least four things to us:</p>
<ol>
<li>A collaboration / learning system</li>
<li>A framework for building collaborative tools</li>
<li>A community of schools, affiliates, and generally cool/brilliant people</li>
<li>A foundation of visionaries to steward 1-3</li>
</ol>
</blockquote>
<p>It must not have been too far off, as Michael said something nearly identical in his <a href='http://www.youtube.com/watch?v=TjIXGFQJ4SI'>overview video</a> about a month later.</p>
<p>This sets the stage for our present unease. We are definitively not evolving Sakai 2.x into Sakai 3.x. This invalidates points number one and two, and the perturbation becomes obvious to me:</p>
<ul>
<li>We have two product lines. Period.</li>
<li>Everything is being swept up in some imperfect Unified Sakai Theory that does not account for this and its effects.</li>
</ul>
<p>We have two products and the rest overlaps by some yet unknown amount. If you like numbers, that means we have two #1’s, two #2’s, a blurry and dynamic #3, and a shared #4. We also hope for a #5: a compelling hybrid/migration mode or, more generally, a way that our products can work together.</p>
<p>The <em>problem</em>:</p>
<p><em><strong>We are treating the transition as an upgrade and picking up bad behaviors because of it.</strong></em></p>
<p>So, to my perspective on reality:</p>
<p>We must accept that open source “fans out” with maturity. Adopters will be on old stuff, whether by choice or circumstance. Any attempts to push someone when they don’t want to or can’t move defeat the spirit and are bound to build resentment.</p>
<p>No one can declare end of life for 2.x. Contributors can reallocate. Adopters can migrate. People and groups will jump on 3.x when they are compelled to do so, whether by attractive features, institutional mission, or unmet needs (as by 2.x or otherwise).</p>
<p>The two products are at very different stages of the life cycle and have very different needs. Our Product Development Process has been conceived in terms of a mature, single product, into which projects are folded and from which outmoded pieces are removed over time. This model does not address the needs of a brand new, parallel core or when or if that core becomes a product into which projects are folded. Trying to solve the problem of how 3.x fits into and changes a single model ignores too many realities for me to be comfortable.</p>
<p>And, finally, parts of what I see as a <em>solution</em>:</p>
<ul>
<li>Make a <strong>clear decision</strong> and statement <strong>about 2.8</strong>, including Foundation and institutional <strong>priorities and commitments</strong>, rather than the fuzziness that has prevailed.</li>
<li>Let the <strong>2.x conversation</strong> and decisions happen <strong>out in the community</strong>. If centralized resources are planned to be shifted, clarify them and allow <strong>community members</strong> to <strong>step up</strong> to these gaps <strong>or adjust their expectations</strong> accordingly.</li>
<li>Remember that open source software far exceeds the reach and lifespan generally anticipated. <strong>Adopters</strong> can <strong>persist</strong> long after contributors move on and appreciate clarity about changing levels of support. <strong>Adopters appreciate clear opportunities and needs</strong> for contribution. <strong>Adopters do not appreciate threats</strong> of their contributions being unwelcome – <strong>they <em>will</em> fork or leave.</strong></li>
<li>Reach consensus and clear statements on the <strong>charges of the various teams</strong>, explicitly treating 2.x and 3.x. Seek announced, <strong>single points of contact</strong> (named dropbox lists or people), if not leads, so concerns can be delivered and addressed expediently.</li>
<li>Revise the <strong>Product Development Process</strong> to account for two parallel products and understood roles. If it is tuned to how we see <strong>2.x, leave it be</strong>. If not, fix it. <strong>Write a new one for 3.x</strong>. Do not shoe-horn one into the other because we have years before they have the same shape and <strong>they need different support now</strong>.</li>
<li>Recognize that all of these <strong>teams</strong> (and the Foundation staff and Board) <strong>overlap considerably</strong> (especially over time), primarily because <strong>people want to do work</strong> to move the community forward and join up eagerly. Try to hear opinions, suggestions, and objections as <strong>ideas from colleagues</strong>, not as formal positions of some authority body.</li>
<li>Consider the new definition of “Sakai”. <strong>Disentangle the overlapping pieces</strong> and figure out the highest level organizational summary:</li>
</ul>
<p><strong><em>What are the “you need to think of” items that go in the next overview video?</em></strong> -NB</p>
<hr />
<p>I should also mention that the timing of this reflection is unfortunate. It has absolutely nothing to do with Michael’s departure; only the 2.7/2.8 process and Product Council homework. Michael has always entertained my rambling exceptionally graciously and usually informed me of something I misunderstood or took too emotionally. Were he to be continuing with us, I’m sure he would do the same here. I genuinely wish him the best on his new opportunities. Remember to set your alarm clock forward an hour for Monday!</p>
<pre><code>From: Noah Botimer <...>
Date: March 10, 2010 10:08:13 PM GMT-05:00
To: Nate Angell <...>
Cc: Michael Feldstein <...>
Subject: Re: SPC homework
I'm trying desperately to protect the remainder of this week. I think a time
next week is best for me and will give a chance to reflect some.Since I just
chatted with Nate, I'll mention this for Michael's benefit:
I'm having a bit of trouble making meaning of the action item. I'm suffering
from a blank page / flux / bootstrapping problem, where everything we have
structured is from a different, simpler, more understood era. This makes the
bullet point very confusing to me now.
I've pieced together some skeletal thoughts but they are young. I need some
processing time to hold even one possible future in my mind in sufficient
clarity.
I think this rephrased question is a good one to consider, but I'm not ready to
do it in congregation.
This is all, of course, unless there is a clear definition that I can
understand and get with.
Thanks,
-Noah
On Mar 10, 2010, at 9:23 PM, Nate Angell wrote:
the 3 of us should set up a call to discuss our SPC homework, which is defined
in the SPC etherpad as:
"Moving from incubation to product development"
but which I'm maybe more willing to view as something more like:
"what form should the SPC's stewardship of Sakai 3 releases take?"
do you guys have time this Thu/Fri?
I'm pretty free Thu. On Fri I have stuff scheduled 12:30-2 and 3-5 ET.</code></pre>
</div>
<div class="post">
<h1><a href="/posts/2010/01/12/dirt-grass">Dirt & Grass</a></h1>
<p class="meta">January 12, 2010</p>
<p>Dirt and grass are beautiful. Rocks, twigs, and bugs, too. Sometimes this world recognizes only majestic cathedrals, all too happy to look past the essence of life.</p>
<p>This is a corollary to something I’ve been struggling to articulate lately. Open source has made it; and because it has made it, people want to make it big. This is fine. I don’t have a problem with big companies, big projects, big money, and the rest.</p>
<p>Where I get uneasy is when people cultivate the sense that the fundamental distinction of free software is just access to source code, or the even simpler view of having no licensing cost.</p>
<p>No, this isn’t what really gets me.</p>
<!--more-->
<p>What really gets me is when we propagate the notion that open source software is just the next piece of some empire-building puzzle – that the value lies chiefly in the different market pressures that open access and licensing can add to the corporate toolkit.</p>
<p>Sure, these techniques can level out markets or even carve out new ones. Sure, there are areas of innovation that require very large investments, particularly where new hardware or regulations are involved (shaking up the mobile industry, for example). Sure, big companies can deliver on a social mission.</p>
<p>But it’s harmful to assume that “open” is just the newest armor for the same old machine, on its same old world domination path.</p>
<p>We miss the point when we forget that access has always been a key component of open source software and communities.</p>
<p>When I say access, I mean the access of the hobbyist or student or small shop to the tools of creation. Through projects that have essentially no “business model”, millions of amateurs (only in the sense that they do something else for a living) are able to create software, art, and more, all with tools that paid professionals use. The most mature case is that of programming tools (languages, compilers, servers, IDEs, etc.) where the freely available tools are the exclusive kit of many pros.</p>
<p>The impact this has had is enormous. If you have the itch, you can build things. Free tools aren’t a secret anymore. And they hold their own with the commercial tools.</p>
<p>But to get to my point…</p>
<p>It’s perfectly alright to be a hobbyist. It’s perfectly alright to make and share software that doesn’t aim to dominate some market – or even ever be polished.</p>
<p>So much of our technology world runs on dirt and grass – the stuff on the ground level. The driver that reads your keyboard, the TCP/IP stack in a dozen routers between me and you, the library that talks to your IM service.</p>
<p>The open varieties of these and many more are beautiful. They don’t have to be big or marketable to be important and interesting.</p>
<p>It’s far too easy to get caught up in the gears when we talk about who’s going to buy up the next open source database or who’s the most delectable open source target in the groupware or telephony arenas.</p>
<p>One of my most cherished aspects of open software is that there is room; room for everyone, room for multiple projects that do the same thing, room for innovation, room for profit, room for hobby, room for learning. The creative energy is not bound by customers, design training, or anything else if you don’t want. You don’t have to aspire to beating anyone. This doesn’t mean you can’t be a fine craftsman, either, but that the field is open in all directions.</p>
<p>When we talk only of building skyward, we hurt the sense of wonder that is tinkering and the camaraderie that is hacking together in the bazaar. We forget that we have limitless space outward – where there’s a lot of beautiful dirt and grass to play on. -NB</p>
</div>
<div class="post">
<h1><a href="/posts/2009/08/06/tweak-working-copy-poms-without-checking-them-in">Tweak working copy POMs without checking them in</a></h1>
<p class="meta">August 6, 2009</p>
<p>A handy little snippet… This is something I’ve used a few times when I’m hacking in a working copy and need to change POMs for some local reason (usually versioning) but can’t check them back in modified. I’d like to tweak the POMs, work on other stuff, build/test, check everything <em>but</em> the POMs in, rinse and repeat. Here’s a workaround:</p>
<div class='highlight'><pre><code class='bash'><span class='nv'>$ </span>svn st | grep <span class='s1'>'^M'</span> | grep <span class='o'>[</span> <span class='se'>\/</span><span class='o'>]</span>pom.xml<span class='s1'>' | sed '</span>s/^.......//<span class='s1'>' | \</span>
<span class='s1'> xargs -I{} svn diff {} > pom.patch</span>
<span class='s1'>$ svn st | grep '</span>^M<span class='s1'>' | grep [ \/]pom.xml'</span> | sed <span class='s1'>'s/^.......//'</span> | <span class='se'>\</span>
xargs -I<span class='o'>{}</span> svn revert <span class='o'>{}</span>
<span class='nv'>$ </span>svn ci -m <span class='s1'>'whatever'</span>
<span class='nv'>$ </span>patch -p0 < pom.patch
</code></pre>
</div>
<p>Happy hacking. -NB</p>
</div>
<div class="post">
<h1><a href="/posts/2009/08/04/graceful-ajax-degradation-progressive-enhancement">Graceful AJAX degradation / progressive enhancement</a></h1>
<p class="meta">August 4, 2009</p>
<p>In one of those beautifully lucky moments, I found an article I was wishing I had kept track of last night. I was chatting with Chuck and Matt a week ago about the pervasion of script in web pages these days and how hardly anything degrades reasonably. For years, I refused script entirely but, now, I have fallen victim to the trend. “Everybody has script enabled anyway. Mashups are inevitable. They want AJAX. Just script it.” That doesn’t mean that I don’t still want to use <a href='http://elinks.or.cz/'>ELinks</a> deep down.</p>
<p>So, I read one of those articles a while back where you feel a little bump and realize someone has lighted the path – with the best kind of light, showing the unnoticed obviousness. It’s like observing that HTTP actually works pretty well when you use it as carefully built, ten years after working around it furiously. It’s like noticing that really ugly <em>(well structured, unstyled)</em> web pages take the most beautiful CSS easily.</p>
<p>But I lost the article. And my recollection didn’t do it justice or support the point that you can script the snot out of a page without breaking Lynx. Then I read the Thread on Safari support in Sakai, mentioning <a href='http://developer.yahoo.com/yui/articles/gbs/'>Yahoo! Graded Browser Support</a>. And something snapped; I thought this may have been where I found the article…</p>
<p>The article was on <strong><a href='http://domscripting.com/blog/display/41'><em>Hijax</em></a></strong>.</p>
<p>This is a cute name Jeremy Keith came up with for an approach to adding AJAX magic without breaking the basic function of web pages. It’s more or less a philosophical first principle of modern web development. You should read this article daily and soak it in like the <a href='http://www.canonical.org/~kragen/tao-of-programming.html'>Tao</a>. -NB</p>
</div>
<!-- links to prev and next pages for browsing thru archives -->
<span id="older"><a href="/page2">Older Entries »»</a></span>
</div>
<div class="span4">
<h2>About</h2>
<p>...</p>
</div>
</div>
</div>
<footer>
<p>© Noah Botimer 2012
with help from <a href="http://jekyllbootstrap.com" target="_blank" title="The Definitive Jekyll Blogging Framework">Jekyll Bootstrap</a>
and <a href="http://twitter.github.com/bootstrap/" target="_blank">Twitter Bootstrap</a>
</p>
</footer>
</div> <!-- /container -->
</body>
</html>