http://tags.library.upenn.edu/winkler4/strategic_directions PennTags Feed http://tags.library.upenn.edu/makerecord/url/12766 http://tags.library.upenn.edu/makerecord/url/12766 <blockquote>Shale is a modern web application framework, fundamentally based on JavaServer Faces. Architecturally, Shale is a set of loosely coupled services that can be combined as needed to meet particular application requirements. Shale provides additional functionality such as application event callbacks, dialogs with conversation-scoped state, a view technology called Clay, annotation-based functionality to reduce configuration requirements and support for remoting. Shale also provides integration links for other frameworks, to ease development when combinations of technologies are required.</blockquote> http://tags.library.upenn.edu/makerecord/url/12281 http://tags.library.upenn.edu/makerecord/url/12281 <p>Eric Raymond's white paper on the lessons learned from open source software production.&nbsp; I capture these to assist in my thinking as we go forward with PennTags development.&nbsp; The Cathedral model represents a closed, commercial approach to software development while the Bazaar represents the OSS model of development.<br /></p><ol><li>Every good work of software starts by scratching a developer's personal itch. <br /></li><li>Good programmers know what to write. Great ones know what to rewrite (and reuse).</li><li><span class="darkgreytextbold">&quot;Plan to throw one away; you will, anyhow.&quot; (Fred Brooks, &quot;The Mythical Man-Month&quot;, Chapter 11)</span><br /> Or, to put it another way, you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.</li><li>If you have the right attitude, interesting problems will find you.</li><li>When you lose interest in a program, your last duty to it is to hand it off to a competent successor.</li><li>Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.</li><li>Release early. Release often. And listen to your customers.</li><li>Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.<br />Or, less formally, &quot;Given enough eyeballs, all bugs are shallow.&quot; I dub this: &quot;Linus's Law&quot;.</li><li>Smart data structures and dumb code works a lot better than the other way around.</li><li>If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.<br /></li></ol> http://tags.library.upenn.edu/makerecord/url/11761 http://tags.library.upenn.edu/makerecord/url/11761 Here's an example of what I think is happening...and how do we talk about this?&nbsp; Are you with this?&nbsp; Risk is everything...<br />