Tuesday, October 10, 2006

97X bam the future of rock n roll

WOXY bam the future of rock n roll is coming back to life once again and it sounds like it will be even better than ever (except when it was an FM station). Yay!

Tuesday, October 03, 2006

Open Source in Government

I find that the ideas of transparency in open source software development and transparency in government align conceptually but not apparently in practice. This post grew out the growing unrest with regard to electronic voting machines. It contains a number of incomplete ideas that I'm publishing just to get them out there...

Free Software Consumers
I think that our governments should, when possible, use open source software and open standards rather than commercial software and proprietary standards. The key part of that sentence being 'when possible'. I acknowledge that in many circumstances there is no open source replacement for necessary software. I don't think that inertia should be an argument against change though. Just because an office is already used to used a particular product doesn't mean it should forego the expense of training employees on a superioir product. In my view a superior product is one that improves one's freedom. This is the precise nature of free/opensource software. It improves the user's freedom. Our government, which is an extension of ourselves, should not be subject to the motivations of a for-profit corporation if it can be avoided.

Open Source as Public Record
I think that the software that executes critical governmental algorithms (like voting terminal firmware or tax calculating code) should be made a part of the public record like laws. If we are governed by an algorithm then we should have the right to know how it works and we should have the ability to verify that it is being executed faithfully.

Department of it/software
The first question that comes to mind would of course be 'Where will all this software come from?' Surely we can't expect it to just crowdsource itself into existence spontaneously. Perhaps there could be something like an official government Department of IT/Software. It's purpose would be to create software products to meet the needs of the various other governmental bodies. This would operate like a hybrid of a software company, an open source project, and a Parks Department. It would have paid software developers to manage projects and write code. It would also keep all source code available to the public online and accept code submissions from the public. I imagine the governmental employees being something like Park Rangers watching protectively over the development and prudent use of the public (software) resource.

Bounty for Diebold firmware
Another route to getting open source software written is offering bounties. This is a common tactic for getting people to code things that necessary but perhaps not particularly interesting. If I had a lot of money or if I were a foundation dedicated to the public good I would offer a bounty for someone to release a free/opensource replacement for the software that runs on Diebold Voting machines. It has been shown that these machines are vulnerable to compromise (reference). If a publicly vetted software suite was available and ready to be simply dropped into place, then those in control of such decisions might be persuaded to mandate the use of the free/open software.

FLOSS has a place in Libraries

I'm a big fan of F/LOSS (Free/Libre Open Source Software). I'm also a big fan of libraries.

A recent post librarian.net reminds me why I'm a big fan of that blog.

Is YouTube the future of Political Debate?

A recent post on Designing for Civil Society asks Can you YouTube?. The participatory "Web 2.0" is making another step into politics with the site e-democracy.org. The site is aggregating content from multiple sources regarding the Minnesota Gubenatorial Debate amongst other projects.

In theory it should be rather easy to put together aggregation sites like this based on any topic.

See also GeoPoli for an example of auto-generating YoutTube video blogs of political content.

Tuesday, September 19, 2006

Cincinnati Wiki Revisted

I've been recently coming to realize that I have an internal idea of what a good wiki is like, and what features one ought to have. I have been participating on and off in wiki for quite some time, and I've surfed through more than my fair share of them. These are the things I have come to see as the most important features of wikiness. Missing one of these things makes using a wiki fatally unpleasant.

Recent Changes
There needs to be a page on the wiki where anyone can view the most recent edits. This is useful for people who want to watch to see if particular pages are being edited or not. It gives the people watching over the wiki, a one-stop place to see anything that is happening anywhere on the wiki. It is also useful when a new visitor come to the wiki. It shows the "current events" so to speak, and it gives and idea of how much action is occurring on the wiki. It shows who is editing and how often. To some degree it indicates the nature of the community that uses the wiki. Recent Changes is the pulse of a wiki.

Serendipitous Linking
It has to be extremely easy to create links to other wiki pages, and there should be naming conventions that make it likely that pages will be linked to. One aspect of this is making it dead-simple to create new wiki pages. This helps people get ideas out there and into the hands of the community easily. Taking time out to think about the linking mechanisms interrupts one's train of thought. When you can link to an idea inline, without stopping the expression of the current idea it lends great freedom to thought. Another aspect of this is that pages have more value when other writers can link to them accidentally. It should be likely that someone could link to a page already written without knowing whether it already exists or not. I personally like CamelCase for this purpose, but I have begrudgingly grown to accept [links that look like this]. Even more important than the technical link markup is the community-developed naming conventions. Serendipitous linking is what makes the flat hierarchy valuable.

Open Editing
It should be possible to edit the wiki easily and anonymously. I concede that for some purposes, logins and wiki-lockdowns are useful or necessary. On most wikis there is always something useful that can be provided by anonymous editors. This can range from spelling and style fixes to sensitive information from parties that value anonymity. The barriers to editing should be as low as possible. This encourages both casual editing and participation by outsiders or new community members. The more comfortable people feel making changes the better.

Version History
The reason wiki participants should not fear a low barrier to entry is that anything can be undone. Reversion to older versions should be as easy to do as editing a page, if not easier. Additionally, it should be possible for readers to see how a page evolved over time to get a sense of its meaning and trajectory. This is what safeguards pages from those that would harm them.

Minimal Markup
This has to do with both the serendipitous linking and the low barrier to entry. When someone wishes to edit a page, they should be able to write without the mental overhead of marking up their words. Fancy markup should be kept to a minimum. This means easy and intuitive methods for formatting text like *bold* and _italic_. This means URLs should be auto-converted to hyperlinks. HTML tags can be permitted but it should be possible to do most text-formatting tasks with little or no knowledge going in.

What Links Here
For any given page in the wiki, it should be possible to find out which pages link to that page. This allows people to better understand how wiki pages and the ideas they represent relate to each other. It gives a view of the neighborhood of the page which helps to understand what the page should say. Also, if a page's content or meaning are altered, there is a mechanism for finding the references to it, so that they can be examined and changed if necessary. This enhances the cohesiveness of the wiki.



Cincinnati Beacon Wiki
So, that was a long way of saying that I'm not entirely satisfied with the Cincinnati Beacon Wiki. It only has a few problems, but I feel slightly inhibited from continuing to edit it. I have not brought my grievances up with The Dean of Cincinnati yet, but I may. Perhaps he'll even read this post. The biggest problem with it may simply be that it is not yet inhabited with much of a community of users, which is not necessarily an inherent fault.

In any case, I have found myself wondering if I could go ahead and try to implement my ideal Cincinnati wiki on my own. I have been considering my options, and I think if I were to do it, I'd go ahead and register a domain name and purchase some hosting for the project rather than trying to go via the Wikia or hosting it on my own personal server. So that leaves me with a little research to do.

I'm still reluctant though because I'm biased against forking if forking can be avoided. I'll be sure to post as I think about the issue more...