Archive for January, 2007

Entrepreneurs, Start your Engines

Posted by Jeremy on January 31st, 2007

Well it seems the eBay has decided to ban auctions of virtual goods, which puts the kibosh on the next Million Dollar Home Page. Any internet entrepreneur worth his salt must be jumping for joy as this cuts eBay out of a burgeoning market as more and more people are auctioning their domain names, pod casts, web advertising, pixels, software rights, publishing rights etc.

I can understand why eBay is doing it, it’s got deep pockets and is fodder for any would be litigator. However I give it less than a week before we see a slew of sites hitting the nets trying to capitalize on this new gap in service capabilities.

The Web 2.0 movement, thankfully, has lost much of its hotness and most people are recognizing that it existed somewhere between what was described by whack jobs and skeptics. This is mainly due to the fact that the average consumer is still pretty happy with eBay and Amazon, and swapping a sluggish interface for a snazzy one didn’t compel people to learn new stuff - especially when the merchandise isn’t any cheaper.

So, anyone with a reversed engineered eBay out there?

LiberalLab - The Model & More

Posted by Jeremy on January 31st, 2007

Some of you, assuming you read the previous post, may be wondering why I rambled on for so long about the Model 2 paradigm - well it’s going to be the premise of how I design LiberalLab. The idea here is that I’m going to sketch out a basic idea of what the model, view and controller are going to be and then I’ll go about figuring out how I’m going to code each of these pieces up. Since we’ve already divided our application up into 3 major sections, it makes sense to do the same with our design, we’ll leave the parts that require integration for a bit later.

Social Network Model

The social network is probably our most primitive application in the system. It’s going to be a series of forms that user fills out after signing up that details some aspects about them, the remainder of the information will simply be generated automatically by the system.

What do we want to track? Well, we’re going to want to have the person’s name, professional title if relevant, a few pictures, a brief write up about them, top 5 most important political issues to that person (perhaps selected from a list?), policy discussions they are taking part in, policy discussions they’ve signed up for, a link to their blog karma score, other user comments.

Other features that we may want to include once we’ve got these basics are a latest posts and latest policy suggestions list. This would display all the posts you have permission to read that this other person wrote. A friend’s list ala MySpace would also prove well, but I think it would be wise to limit this to people who know each other outside LiberalLab, given that the audience for this is going to be pretty small sub 10,000 or so we don’t want everyone friending everyone else on the network.

We could also include an RSS dump of their blog, users could drop the RSS/Atom link for their blog and it could display their entries right there on the profile.

Badges

This is an idea that although hokey when explained is astoundingly effective when put into practice. The idea here is to create boyscout style merit badges for various accomplishments via LiberalLab. They can be anything from 100 forum posts badge, 200 karma on a single post badge, a badge for each policy discussion a user takes part in etc. It sounds juvenile and in many respects it is, but the numbers speak for themselves in various communities including open source projects - people will work for them. The idea is to use the badges as a prestige system in addition to the karma - the badges are accrued whereas karma is used like currency. The administration can encourage certain activities by creating badges as incentive - it sounds ridiculous but anyone who uses Xbox live knows the insane lengths people will go to to collect them.

A small discussion of Model 2

Posted by Jeremy on January 29th, 2007

Xerox PARC gave us a wonderfully useful way to think of how to structure software called estoerically enough Model 2. Most people know this as the acronym MVC, this stands for Model View Controller. MVC is likely the most frustratingly useless acronym ever as not only does it tell you very little about what Model 2 is what it does tell you is wrong. A more accurate acronym would be MCV or VCM.

The premise behind Model 2 is pretty straightforward, it’s significantly less complex than people make it out to be. The first thing you have to remember is what software really is. Software is a tool we use to interact with a “system”, that system can be entirely encapsulated within the software or that software can exist within a greater system. An example would be the catalogue search terminals use software to search for books – it’s part of the system but it’s not the system in its entirety, the same is true of the software running the check-out terminals or the public access terminals. Software is a way for you interact with the system that’s different based on the tasks you wish to perform.

So the first thing is the model. All the software that allows you to interact with the library system, even things like their website share the same model. The model for each application will likely be incomplete but not contradictory. For example, the public access terminals don’t need to know about the books but they DO need to know about library memberships. The search terminals don’t need to know about library memberships but do need to know about library cards. Both of these share the same model because whatever domains they both cover are in agreement. A check-out terminals understanding of a library card is the same as a public access terminals. All these systems have the same understanding of how the system works.

Let’s narrow our focus and talk about the search terminals. The aspect of the library model search terminals are concerned with are books. Now, books have a bunch of information such as titles, isbn numbers, publishers, authors, subjects, and check-in statuses to name just a very few.

The model is the structure of the information and the information itself – this is important because if you change either one of these you have a different model. Also, 99 times out of 100 the model will be represented by a database system in software if it isn’t a database it’s something that behaves just like one.

Now, the user should not have to be placing SQL queries and interacting with the model through it’s “generalized” interface. We want something that is tailored to searching for books, right? So, we create an interface for viewing books in a fashion that makes sense for books. We have them sorted by title, we even have little pictures showing up next to them of the book covers. ISBN numbers are listed after the titles and we’re even presented with the status of the book and an option to put a hold on it.

What I just described is the VIEW, it’s our little portal – our HUD to the model. The is the template into which we inject our specific information. The search results for “Moby Dick” look very similar in layout to the search results for “Information Theory”, the difference is in the content. All those things that look the same from search to search are part of the view, the content itself is the model.

Wait, didn’t we miss a step? What about the controller? The controller converts the structure of the model into the layout of the view. It’s the middle man that organizes and presents things in a way defined in the view, it also does the reverse. Searching for something? Well, you put in your query and the controller converts that query from something a person understands to something a computer understands, and does the reverse with the results sent back by the model.

Why is this special? Well, it’s another very useful principle in software engineering called “encapsulation” or “separation of concerns” - the two are roughly interchangeable. The idea being that the view doesn’t have to know about the model, and the model doesn’t have to sort things in any special way for the view. Say, for example, we have a search function that should run on a Palm. Well, we’d have to create a new view and define a new way for the controller to convert from the model to the view. Having a single model allows for all sorts of different software to interact with a single repository of data.

Rather than create a separate system for storing books for searching another for checking them in and another for adding new books to the collection. A library can simply create new aspects to the view and controller that interact with the single model – which is like the rosetta stone for all these systems.

The final point regarding Model 2 is that it has a V shape in terms of plurality. There is only a single model, the controller is at least as big as the amounts of elements in the model, the view on the other hand is as big as there are ways to interact with the system.

Why is this important for LiberalLab? Well, liberallab is going to have a single model made up of forum posts, users and documents. The controller will have to manage the forums, user creation, documents as well as specialized features like document-discussion parity and karma management. It’ll also manage all of our validation of inputs to make sure no one hacks our site or gives us nonsensical information. The view of course will be the method that users interact with the system. Initially we’re building it for looking at in a browser using XHTML and some RSS / Atom output as well.

It might be worthwhile, in the future, to build versions usable from mobile devices like Blackberries or to build web services (a special kind of machine-readable view). However, since we’re using Model 2, these can be built later without having to alter anything out of the device specific code.

LiberalLab - Technical Stuff pt. 2

Posted by Jeremy on January 28th, 2007

Okay, so we’ve decided on a few things about LiberalLab so far. It’s going to be written using PHP, it’ll be DB independent or at the very least work with MySQL and Postgres. It’ll use the symfony PHP framework for the most part. Since it’s PHP/MySQL it makes sense to use Apache as our webserver.

What sort of usability/accessibility requirements do we need to keep in mind from ground zero? Well, I don’t think we have any particularly unusual requirements except that the system should be easily translated into French and English (maybe we could provide karma to those users who diligently translate pages). This means navigation options and the like need to be text rather than images.

Usability considerations are pretty straightforward, make what you’re supposed to do at any point easy. The Karma system is going to have to have some well designed affordances since it’s an unconventional tool. The forums are going to have to be simple and feature spartan. I think I’ll use that javascript package (it’s in Wordpress) to allow advanced text editing.

However, the obvious question is considering this is simply a slightly more advanced synthesis of 3 systems why re-invent a new system. There are plenty of Content Management Systems out there (www.opensourcecms.com has a few to try out), there’s also plenty of PHP forum software out there Simple Machine Forums, PHP BB, YaBB, Ultimate BB etc. Social networking software is more or less built into most CMS apps nowadays.

I think it will, in the end, prove more useful to build from scratch than to try and integrate by developing packages for each of these apps. Firstly, I’d have to learn at least two architectures, and so would every other developer for the system. LiberalWeb used Drupal fused with SMF for its setup and it produced a workable product but having attempted similar feats with Joomla, Mambo and other CMS with various forum packages to see if any would be better I can say I would rather spend 6 hours coding exactly what I want than 4 hours configuring something that sort of works the way I’d like it to.

Plus, feature focus for most of these applications are in the wrong direction. MediaWiki has strong authorship tools but a very weak forum system. Drupal has a good forum integration and social networking tools but its collaborative authorship tools leave a lot to be desired. Plus, it’s not only what we want in the system, it’s the rather specialized way in which we’ll use it. For example, the wiki isn’t really a “wiki” it’s a collaborative authorship tool for a select group of people. Plus the enforced parity between discussion and wiki would require some major tinkering in both MediaWiki and any forum application I’d likely use.

So, we’re building from scratch – but not entirely. Symfony offers a quick mechanism to get basic functionality down, and once we’ve got some mockups of the kind of user interfaces we want we’ve basically covered the hardest of the three steps in Symfony, the view. The model is dead easy to create and the controller is more or less automatic when the view and model are defined.

Don’t know what model, view or controller are? Wait until next post where I’ll explain what those are and how they’ll fit into LiberalLab.

LiberalLab - Technical Stuff pt. 1

Posted by Jeremy on January 27th, 2007

Okay, we’ve got enough understanding of what we want the system to do to begin at least a rough prototype of some of the interfaces. I, for one, like to build from the interface backward. Some computer engineer types like to start with the model of the system and then develop the required mechanisms to manage and interact with that model from there – the problem with this is that a client doesn’t usually understand a database schema.

Clients DO understand a prototype of the interface they’ll be using and can provide valuable input. Sticking a stack of DB schema sheets is similar to handing someone the blueprint to their office complex to ask if they like it.

Some other technical questions I need to answer are what sort of technology am I using to build this sucker. The first constraint is cheap-as-free. This isn’t a huge constraint when it comes to web apps as just as often the free stuff is better. The second constraint is ease of development, both for me and whomever else might come along and want to contribute – which means that although I could do it in Ruby or Python or heck Algol or Smalltalk I’d prefer not to force people to buy 3 inch books to learn how to take part. That does limit the choices considerably. PHP is a popular language and is very easy to learn relative to most object oriented languages. Building a custom JSP taglib would be useful and powerful and having a Java backing would make the system portable but the development time to setup the basic plumbing and the complexity of initial set up would be prohibitive. If precedent were any tool then PHP would certainly come out on top.

Perl is not really an option as it’s simply too clunky for me to develop a web app in compared to what’s out there. C# would be useful, I’m familiar enough with ASP.Net to build something with it however it contravenes the cheap-as-free if we were to go with the .Net setup. I have zero experience with Mono so I wouldn’t want to take it into something production destined.

Ruby is still relatively obscure, though growing in popularity especially amongst new-to-programming types. I don’t mind the language and it’s well suited for this kind of project – however I do not like Rails for a number of reasons I won’t get into here.

PHP looks to the language. I think I’d like to use a framework to build this system as starting from scratch would just tack on another 30% to the already too-long cycle. Not to mention having a framework gives people a documented starting point to help them figure out the system, I don’t think I’m going to heavily document LiberalLab’s code, mainly because it would take me more time to write the documentation than it would for someone to figure out the code without it given the simplicity of the system. Having a framework would make things easier since I would do everything in a standardized fashion.

So, which framework? There are plenty out there – Cake, Zend, and Symfony are the ones I have the most familiarity with. Zend is the most flexible and powerful by a long shot, however it’s also pretty damned rigorous and customization heavy, too carte blanche for this project. I don’t particularly like Cake’s system, I find it’s conventions too idiosyncratic and irrational for my tastes. I recognize many of the conventions are work-arounds to limitations with rather narrow PHP – but those limitations are known and understood and accepted when one works with the language. Symfony is actually very rails-like but since it is based on PHP rather than Ruby and uses Apache rather than a totally useless web server I prefer it. Also, Symfony allows parallel development for different DB environments.

Speaking of DB, which are we going to use for this system. Well, I find MySQL much easier to work with from a development standpoint because I’m considerably more familiar with it. However, I recognize it has pretty serious limitations in a production environment. Granted, I’m not creating a new stock exchange and my DB strain is going to be slight, so I don’t need to worry TOO much about capacity. Postgres is still the trusty work horse DB environment and I think I’ll want to use it in production – since Simfony makes multiple DB / multiple environment development easy there’s no reason why I can’t use both.

I want to use AJAX, definitely. I don’t think I’ll deliberately AJAXify every god damned thing on the system but it would be useful here and there for interactive features and form validation. We’ll cross the AJAX bridge when we get there. I usually make “AJAX ToDo:” notes on my form prototypes.

LiberalLab - Quick and Dirty R&D

Posted by Jeremy on January 25th, 2007

One thing I’ve discovered in doing software engineering is the amount of time teams spend either solving problems with obvious or ready made solutions or, worse still, elaborately articulating found solutions in the vernacular or specification format of the project. I can actually recall a team member meticulously creating UML diagrams of a web application that we were using as a template for interface design. Ridiculous!

When I did graphic design and was hunting about for design inspiration or solutions to problems I faced, I would hunt through magazines, websites, newspapers etc. If I found something I could use I would either tear it out or bookmark it, I would attach a sticky or fill out the comment field with a brief description of what I liked about what I saw and I’d go on my merry way.

As my friend Chris often say cynically - R&D stands for Ripoff and Duplicate. So, with that in mind, here’s some examples of sites that are roughly what it is I’m trying to create. The caveat here is that these sites are geared for slightly different audiences or purposes so retooling them may or may not be more costly than building an app from scratch. However - I haven’t eliminated the possibility, certainly.

1 - Taking It Global

What is it?

TiG is a website primarily for youth to discuss global issues. Though ostensibly for youth the age range of the audience of the site varies pretty widely. The system has a profile page - like a social issues focused mySpace where you list your causes and generally make a show of how sensitive you are to the plight of X or destruction of Y and list the books you’ve read on it, camps you’ve been to, trees you hugged etc.

How does it work?

Thou shalt pulleth out the Holy pin and count to three…. TiG retains message boards and also has the capacity for users to generate mini-tutorials or primers on the various issues they’re concerned about. You have a home page which aggregates all the basic information that you’ve decided to track (your messages, forum posts for forums you’re interested, news items etc.) The structure is quite loose and there’s no central focus for the entire group of the website.

Why do I like it?

Well, it has a huge variety of widgets and tools to serve practically any activists to-do ilst. Need to create a workshop? No problem, there’s a workshop generation wizard for you to create. Need to start a long-term project? Easy, just fill in some fields to start the project. The sheer variety of stuff you can do on the website is pretty cool.

What do I not like about it?

Firstly, it’s got a pretty dated interface with some pretty vague/confusing navigation options - usability nit picking aside though it’s a solid interface. Although there’s lots of stuff for one to do, its usefulness is debatable. There’s e-Cards for example, this is the “we need another feature” feature, as no site should have a spam tool built for its users. Plus some of the aggregation of tools are labeled as something they’re not REALLY. For example, the “Project” tool allows one to create a mailing list, a photo gallery, a forum and a document repository - these things do not a project make. Where’s my scheduling tool? My resource management? Gantt chart maker? to-do list manager? accounting tools? Adding just one of these pretty basic tool (go grab an open source widget) would make the difference.

What can we learn/use from this?

Firstly, we can know what kinds of vulnerabilities to avoid. The user interface is cluttered and menu options poorly labeled - so clarity and ease of translation to French will be big things to remember. The separation of factual resources from expressive opinions was intelligent for people who want reference rather than reading material. Organizing everything by issue is also a smart way as it cuts across geographic boundries pretty easily. We can also note that TiG is too loose in its structure, it’s more sandbox than assembly line. We obviously want to a balance in LiberalLab between productivity and exploration, I think putting a time limit on things will likely help as will making most things sequential (which is to say there’s a clear order that you can follow or not at your leisure)

2 Omidyar Network

Omidyar is very much like a grown up TiG. It inherits much of the same “problems” that won’t work with something like LiberalLab - mainly the open structure and VERY loose definition of purpose. Such a mandate would be nearly impossible on something like LiberalLab as we’d have almost as many policy discussions as members - which won’t work. Furthermore, the policy discussions must be practicable from a partisan and governmental standpoint (discussing Canadian nuclear armament although interesting academically won’t fly in the House - I HOPE!)

Omidyar uses a “feedback” system very much analogous to my proposed karma. The interesting thing is that it’s used as a “tax” on generating content - this to me seems economically backward. You want to encourage people to be active in generating whatever they feel they need. In Omidyar it costs points to create things like discussion groups (something a normal user can’t even do in LiberalLab as it stands) polls, etc. Now, I suppose the idea would be you foot the point-bill in the hopes it will pay off in positive reviews, making sure people don’t post crap. However, the risk of negative reviews is still present in my system and there’s no adverse selection by charging people karma to create things. One thing I did notice when looking at people’s “feeback banks”, especially the top listers was there was some people seriously hoarding their points. This is not what we want in LiberalLab, saving the points for a few days is one thing but accumulating them over a long period of time is different entirely.

Having a half-life to your points is probably a good mechanism to use, since the people who get the largest quantity have most to lose by hoarding them. There could also be an absolute points earned versus points available.

There could also be alternative methods to point gain - so the more points you have available the harder it is to earn more - pushing the bar higher on a person by person basis. So the actual points earned is a function of your current points and the points attributed.

As far as the rest of the site omidyar seems to follow a pretty standard template for these kinds of sites - a forum/profile + widgets site.

3 Sourceforge.net

Sourceforge, after I thought about it, is the closest thing to what I want LiberalLab to be. SourceForge provides an application to develop open source application. The community of users subscribe to various projects as developers to gain access the project resources and take part in development. Projects have certain properties that can be used to sort them and all the tools are built around getting software made - whatever community infrastructure exists is built around productivity.

Sourceforge also functions as a clearing house for the software projects built with it. SourceForge has various partners who mirror the content of the entire site - providing free file hosting for the project developers without them having to secure it individually.

Sourceforge’s weaknesses will likely be avoided in LiberalLab. SourceForge has a HUGE quantity of abandonware,  as it is trivial and automatic to start a project. In LiberalLab - the projects themselves will be predetermined or generated by popular support - no single individual can start any project of their choosing. Avoiding SourceForge’s other issue of duplicate or competing projects.

4 Wikipedia.org

There’s a great deal to be learned by Wikipedia’s model - perhaps more than any other website. It’s the biggest collaborative authorship application out there - by a long shot. However, there is a not-so-subtle difference between Wikipedia and LiberalLab - LiberalLab is normative, Wikipedia is quite obviously not. Wikipedia does offer a discussion framework but it is VERY primitive because most often there is simply disagreement over specificity of information, quality of articulation or simple factual accuracy - it works for their needs. Furthermore, the parity between discussion and article is not automated - it is structured by the legions of Wikicops who patrol the site looking for things to fix, adjust and tweak. While we will have SOME staff for this it will be relatively tiny and thus much of the basic logistics such as parity, correction, controversy moderation, vandalism detection and such will have to be automated. Thankfully this is more easily accomplished in LiberalLab than in Wikipedia because the narrow focus of articles, increased central control and finite quantity of documents among other reasons.

Community Development

David Eaves made the good point that one must foster the right kind of community to develop a quality open source product (assuming we mean community based open source and not simply code made by a team released to the public). By “right kind” in the LiberalLab I mean, above all other things usefully productive. Meaning they produce easily and what they DO produce is useful. I think, in many ways it’s a Catch 22 when it comes to badly run teams - they don’t produce a quality product, so they don’t feel compelled to work on something crappy so a good product is never made. If the community is kept on task and quality is encouraged/enforced you will find MORE people are willing to become MORE involved in the project. For those of you who’ve read Fred Brooks you’ll know 1 full time programmer is worth more than 2 half-time programmers. The simple math being that a community of 10 heavily involved developers produces better and faster than a community of 20 lightly involved community members, all else being equal.

That said, I think my time limited sign-up and time limited project life cycle will keep teams small and mobile. The trick will be making sure the project visions are on par with the timelines - since we’re dealing with a fixed timeline and a variable specification the projects need to be tailored for the increments.

Communities and Open Source

Posted by Jeremy on January 24th, 2007

Recent commentator and remarkably cool guy, David Eaves, drew my attention to his article “Community Management as Open Source’s Core Competency.” It got me thinking about the properties of open source projects that make them successful.

Successful products are usually made by a tiny team of very focused individuals - in David Kelley parlance “hot teams”. Ideo is my favourite example of a company that is famous for its products but no one can name them. Ideo uses a hot teams which is pulls from various staff members, usually volunteers, to work on a project coming in. These teams never get huge - multiple hundreds of members are out of the question, yet the quality (and complexity) of their work is staggering.

The question I had to ask David Eaves was what was the definition of successful open source software? Ambitious programs that are complex and/or difficult that get made despite the odds? Applications that are very popular, used by millions of people? Applications that are innovative and way ahead of their time?

Firstly, I might point out that open source has serious problems with that last category. Open Source is the generics if software were pharmaceuticals, cheap knockoffs that cost less (or nothing) then the trend setting originals. Often because it’s difficult to generate the buy-in required to produce a product without precedent when you’re dealing with people giving their time away for free. If I were programming something at IBM that had never been made before and may not work at all, at least I can collect my pay cheque at the end of the day.

Secondly, when I think of an open source community I think of it in its totality - user groups, support areas, fan clubs, localization groups, feature-lobbyist organizations etc. The developers are just one part, a rather central part, of the group.

“Open source software firms (like Mozilla, the makers of Firefox) are not software companies, they are community management firms whose community happens to produce a software package.”

This is a fascinating statement and I agree to it instinctively. However, this is analogous to saying GM is not a car company but an organization who owns factories and employs workers to happen to make cars. One could get more abstract and say that GM doesn’t make cars it makes money THROUGH cars. But that brings up an important distinction within open source, profit vs. non-profit.

Linux is non-profit in and of itself - Debian especially but many others - BSD for another. Firefox is designed to make revenue, as is RedHat’s use of Linux as a product to service. JBoss is supposed to make money. Sun Microsystems bets the bank on open source. To these groups, the software is about the money it can make - good software usually makes more money (certain applications from Redmond, WA excepted).

I’ve worked on several open source projects, even started and managed a few small ones. What I discovered is the diversity in how people derive utility from contributing to open source. Some like to experiment with new tech, others liked the nature of the project and wanted to see it succeed even if they didn’t use the product, others wanted to build a portfolio, etc. The most common reason, by far, though, was that contributors wanted a good piece of software they could use and keep for free - they didn’t want anything else available or were unwilling to pay for it. This is apparent when one notices the most common short comings of completely grassroots open source - hideous or absent documentation, poor/unintuitive interface design, useless support.

Oddly, I cannot recall anyone ever mentioning they wanted to be part of a community of like minded people as a reason to get involved in open source. It’s a valid reason, but one I haven’t stumbled across.

As far as commercial open source it’s obvious that the software itself isn’t used to generate revenue but things surrounding the service that do. This is old hat for technology markets - most PCs don’t actually generate profit but printers, mice, service plans and software do. The community needs to be fostered to keep the golden goose laying but this feeds back into the quality of the software.

Although, if the quality of the software were very high one might not feel the need to get involved in improving it whereas if the quality were below the obvious potential of the software you’d spark involvement.

One mustn’t forget that software development is not sweatshop labour - it’s not cheap nor is it something programmers would only do if paid. Even within companies development teams are treated more as communities than employees because these people could more readily quit and move on than a successful accountant, so the lessons learned there are just as important here and the problems described by Mr. Eaves are true even for small teams.

As the product matures innovative leaps become harder. With the low hanging fruit plucked new features and ideas become harder to imagine and/or complex to code. The likelihood of one genius coder solving a problem is reduced. Thus at the same time that legacy governance structure (or lack thereof) makes collaboration more difficult, innovations become more difficult.

Poor software planning leads to situations like this, I don’t think it a by-product of developer mass (to use eXtreme vernacular). Whenever one designs software one must be clear about specification and definition. When a requirement is put in place it defines what an application must do in quantifiable terms. Someone should be able to sit there with the requirements and use the application and check off each item without any real judgment or inference required. The important part is what many forget, anything not in the requirements is NOT being developed - that’s why it’s kind of important to get requirements right and to work iteratively.

David Eaves articulates a sentiment I’ve felt since I’ve been involved in open source technology - even just as a user. There must be a more rigorous process of design and development, one that is involved, efficient and effective at producing great software. Just hit up sourceforge.net to get a taste of how even the best tools can be wasted on unmotivated teams.

I’m sure someone’s done it, but some Rational expert out there should concoct an Unified Process instance specifically geared for open source development.

What’s encouraging to me, was how Mr. Eaves and I articulate the same problem, that is poor leadership and communication, in two different ways - his issue is with community management and mine is with software design and engineering rigor. Shows that I’m not off my chump.

LiberalWeb - More Blue Sky

Posted by Jeremy on January 23rd, 2007

Okay, so in the previous posting we established the basic goal of the system - provide a framework for policy development and discussion that’s centered around time limited productive processes.

The basic framework was established with three sub-applications that interface on various levels - the forum, the wiki and the social network.

Karma Network

One of the features I wanted to include, which will be implemented across all three applications is a Karma Network. The idea here is to introduce a voting system, influence metric, incentive for good behaviour and reward mechanism all in one system. This would be in the form of a kind of currency on LiberalLab - karma. Users earn a base level of karma for being active members - posting to forums, amending policy documents, signing in etc all afford a certain amount of karma. This can be used to review other users’ forum posts, policy amendments and the like. It can be used positively or negatively. A user can give away their karma to a user or conversely can consume their karma by “burning” their own.

The idea here being that users who are popular and/or well respected will get very high karma scores, whereas those who are abusive, problematic, difficult etc. will have low ones. The karma metaphor works well because the more you give away and help others, the more likely you are to receive karma yourself.

People with extraordinarily high karma scores can be featured on the index page, elected into panelist discussion, asked to proffer position papers or think-pieces on various issues etc. The system could even be used as a method of short listing facilitators for meatspace think tanks or other activities, maybe even consultants to decision makers.

Since the scoring is entirely relative, and the total amount of karma available is limited it’s hoped that one would see a “super-hub” structure, where karma is more or less pooled into a single person from a large collection of moderately or slightly popular individuals who collectively throw their support behind a representative.

This system would also prevent overly strong minority groups from gaining a disproportionate share of influence since their collective karma scores would be inhibited due to lack of popular support.

There’s lots of potential here if the functions of how karma is accumulated and consumed are balanced correctly - it could work much like a far more precise and dynamic version of the ballot systems proposed in Canadian elections recently

LiberalLab.com - The Beginning

Posted by Jeremy on January 22nd, 2007

I think for the first few posts I’ll take you my gentle readers on a journey through the process of software engineering, at least its inital stages.

I am involved in the Liberal party of Canada in a very peripheral manner - this is something I wish to change. At to least remove the “very” from that sentence. I worked with my good friend Taylor on a piece of software which showed promise but was more or less left by the wayside when A) we lost the election B) we got involved in a very exciting (and distracting) leadership race and C) the small team we had collapsed.

The experience I had did teach me that there was interest in such a thing and that in order for real development supported to be drummed up a modular, scalable, flexible prototype would need to be built using cheap-as-free technology. It had to be pretty, but not design award winning, and easy to administer, maintain and use.

So, that brings me to where I am, to build the bloody thing. The basic concept is to provide a web application that acts as a policy development platform for n users. It more or less should be a mashup of a wiki with a forum with a healthy helping of social networking, blog and polling software thrown in for good measure.

So really we’ve got five problem “sectors” to define.

1. The Wiki

2. The Forums

3. The Social Network

4.  The Interactions of those three pieces

5. Keeping all this modular, flexible and scalable.
No mean feat but this is actually a pretty good premise to start from all told as we’ve got a solid grounding of what we want this to do and what we do not want it do (often choose what not to do with your software is as important as choosing what you want it to do).

We want parity between the wiki and the discussion forums. The idea being that the process (aka forum) will always be tied to a product (aka wiki) - a policy document or position paper. This avoids policy documents that are the product of a single person, and discussions which are purely pedantic without any real connection to a valuable outcome.

There are some fuzzy areas unanswered, such as security requirements and hierarchy of users. We’ve obviously got 3 types of users at the get-go: administrators, registered users, and guests/un-registered users. We could include two more positions - moderators and “politicos” (for want of a better term). Moderators would exist somewhere between administrators and registered users - they could create forum threads/wiki portions, freeze wiki articles or threads and basically make sure everyone plays nice in the sanbox. They wouldn’t be able to create/delete accounts, or make any system-wide changes or installations, this would be the purview of administrators.

Politicos would be real politcians who want to go in to the system, get a quick digest of the goings on, see the “best in show” documents and get the heck out of there. Their interface would be pared down to a simple dashboard, where they could get a take on the pulse of the discussion - hot threads, popular wiki articles, celebrity members etc. Likely administrators would need a prescribed list of possible users and generate accounts for each of them so it’s a matter of clicking that link in their email to access their tailor made dashboard.

It seems likely to use a “hot team” system for the policy developments - where rather than going on ad infinitum. A policy discussion would be time-boxed. There would be a set, predestined calendar of progression. The process would be well documented so people knew exactly what was happening when well ahead of time. To make this feasible there would have to be pre-development sign-up, and this too would have to be time-boxed so that everyone was involved in the process from day one.  Late comers would have to petition the moderators for admittance or perhaps recruit a sponsor who is already a member of the discussion “team”.

The policy development process could have a roughly iterative framework, a Unified Process instance maybe. It could be a six-week timeline. Weeks one and two would be analysis and design, where the problem space is defined, the scope of the policy is specified, information is gathered, prior solutions are assessed etc. Weeks three and four would be development, the primary wording of the policy is authored, discussion is done section by section or sub-topic by sub-topic. Weeks five and six would be implementation strategies, fact checking, proofing etc.

I honestly have no idea if that’s at all realistic or possible but it seems like a decent solution for now - if it ends up being dumb I’ll throw it out later (I’ll know if it’s a good idea or not by the time it becomes important what kind of policy development process we’re using - I hope.

This time, with feeling…

Posted by Jeremy on January 22nd, 2007

This will have been the fourth iteration of this blog and although I never lose my desire to write I do often lose a central focus to what I write about. It seems, as soon as I settle on a topic I am immediately pilfered of all my ideas regarding that topic and must descend upon another one to make my self-imposed posting deadline.

So, instead of making this a series of dissertations are various topics and whatnot I’ve decided to make it a journal format wherein I out line the various things that I’m up to - in terms of action.

Hopefully I’ll spark some ideas and people will get involved - if they care to.

I’d like to make this site somewhat of a community - much like Scott Berkun has done with his blog/website.

The next few entries I think will chronicle some of my issues in gaining focus as a software analyst and defining what it is I do, and more importantly don’t do professionally - my personal struggle with defining my rather nebulous expertise is a long one and isn’t over yet.

So, welcome back to my various rantings, ravings, dissertations and essays.