Summary: What would the perfect community web site for OS/2 be like?

The Community Hub

Communities always need a hub or anchoring point where they can meet to trade information. For regional communities you have shopping malls and plazas, local newspapers, local radio and TV stations, clubs, community bulletin boards and so-on. For a sparsely distributed community like OS/2 users, the hubs are inevitably web sites and user groups. But communities are often judged by the quality of these hubs, and to be honest, I've been disappointed by the OS/2 oriented web-site hubs that I've seen.

I've come up with a few ideas for a web site that can serve as a true hub for the OS/2 community, and one that should be impressive enough to convince some outsiders to join in. I'm hoping that perhaps a few of the prominent OS/2 web sites (hint, hint) will perhaps build a few of the services described here and compete to see who can be the best.

The Basic Services

Services that we've come to depend on include a good archive of software, a good links collection and a news service. Hobbes fits the archive bill quite nicely and, with luck, won't disappear because nobody will step up to maintain it. The OS/2 Supersite also does this, but not quite as well as Hobbes. Their search engine really needs fixing. The Suspersite has a sizable number of links, but these haven't been maintained nearly as well as the collection found on the OS/2 Warp On the Net site. WarpCast has been a decent news service for the past couple of years and, so the ads claim, is Warp City. The only problem is that one is sometimes a bit slow or sloppy when delivering the news, and the other is a private membership site.

The dream hub, then, would have the file archive of Hobbes -- with its excellent search engine -- the links collection of OS/2 Warp On The Net, and a news service with the scope, availability (and distribution method) of WarpCast but the speed of Warp City.

But, there are a few other things that haven't been quite available anywhere at all. The first is a community calendar where organizers of events like user group meetings can go and post their meeting times, describe their events and provide driving directions. Often you'll see these events posted on WarpCast, but it's awkward to use that as a central posting board for everything that's taking place during the year. It's not really set up to be a calendar the way a "month-at-a-glance" wall calendar is.

Second is a community "Rolodex", which would list the names, addresses and phone numbers of all the vendors that sell OS/2 compatible products. This address book could also list contact information for consultants who want to be known, as well as the mailing addresses of user groups and committees that organize events such as WarpCast. The links collections almost suffice for this, but not quite. They only link to the homepages of these companies and organizations and these pages may or may not list contact information in an obvious place once you get there.

I've thought about including classified ads in this "dream hub", but it occurred to me that the phenomena of online auctions has pretty much killed off the concept of classified ads completely. Why advertise in the classifieds when you can offer the same item on e-Bay and get more while at the same time knowing a third party will help you with the fulfillment? And speaking of which, there'd be little point in having a separate auction manager in our dream hub when e-Bay and the other auction sites are already set up to handle anything at all. As Timur Tabi has been pointing out on WarpCast twice a week, there's plenty of OS/2 stuff on e-Bay right now, so there's no point in diluting this small market further by trying to compete.

The Personal Agents

But here's the killer idea that I'm surprised hasn't been thought of and implemented in all the other portal sites on the web already. It's the personal agent. This is not quite the same as the "intelligent agents" that were of momentary rage a few years ago, but more like search engines that keep searching after you've left them. They work like this:

You program an agent to search for files, or events, or links, or articles for a specific keyword in a specific subject or topic. You then forget about the agent, but the hub where you programmed it doesn't. The agent isn't much more than a record in a database, but every time a file gets uploaded to the archive, or an event gets added to the calendar, or a link gets made, or an article gets written, the hub searches through its database of "agents" for any matches. When it finds one or more matches, it sends an e-mail message to the person who programmed the agent to tell him or her that the requested item has arrived.

Here's a couple of example scenarios:

You've just bought a new digital camera, but OS/2 drivers for it haven't been written yet. You go to the hub and program a personal agent then, telling it to watch the Device Drivers and Multimedia sections of the archive for anything that matches the keyword "Kodak DC220". A couple of months may go by after programming the agent, until finally someone adds Kodak DC220 support to their image capture program and uploads it to the hub's file archive. The hub notices that an agent had been programmed a couple months earlier to look for anything to do with the Kodak DC220 being uploaded into the Multimedia directory, so it sends an e-mail to the agent's programmer to let him know about it, even providing a link to directly download the program.

Now someone else knows he's going to be in San Jose, California during the first week of October next year for a business meeting. If it's possible, he would also like to take some time out and attend an OS/2-related user group meeting or conference if one happens to be going on at the same time in the same city or region. But many user group meetings and conferences aren't usually planned that far in advance. Even the host city for WarpStock isn't known until a couple of months after the last conference. So our traveler goes to the hub, programming an agent to watch the community calendar for any OS/2 related meeting or conference that'll take place in or near San Jose for the first week of October next year. If, in the months leading up to that date, someone does indeed schedule an event for that time and that city (or a nearby city like San Francisco), then the programmer of the agent will get an e-mail letting him know.

I'm well aware of the performance issue that would progressively arise as these agents become more popular and used more often. Even though they'd only be records in a database table somewhere, that table will grow and so will the time it takes the hub to process each incoming file or event or piece of information that's potentially searchable. The only way to deal with the feature's popularity would be to upgrade the server, but there is a way that "upgrade day" can be put off for as long as possible, and here's how:

The agents expire.

They would probably be set to expire about a year after being programmed if they never found what they were sent to look for. They'd expire for sure after they do find what they were programmed to look for, but always with a grace period. About 7 days before the agent is due to expire it would send an e-mail alert to its programmer, giving him the opportunity to return to the hub and renew the agent for another year to keep looking. Otherwise, the agent expires and is deleted from the database if its programmer never comes back, thus keeping the database as trim as possible without being unreasonable to its users.

Agents may also expire early whenever it made sense, and this would usually be with ones set to watch for calendar events. If the agent was programmed to watch for anything that happens within the first week of October, 1999, then after the first week of October had passed the agent would expire - even if it hadn't been running for a full year yet. Since nobody is going to retroactively schedule an event, there's no point in keeping the agent around.

There would also be a limit on the number of agents who could work for a given e-mail address. Let's say five is a reasonable number, giving anyone the ability to have several agents monitoring the archives and calendars and links for whatever might interest them.

Integration

All of these services are magnified in their value when you start to add relationships between them. One of the most obvious ways is the relationship between the community calendar and the community "Rolodex". The Rolodex would be used to keep track of venues for events, such as meeting rooms and halls (there might also be the concept of "meta venues", like hotels and host cities and campuses), with information on seating capacities, driving directions, phone numbers and available utilities.

So say you're the organizer of an OS/2 user group that uses the same meeting place every time. When you come to schedule your next meeting, the venue is already known to the hub and you don't have to re-type all the information again. In fact, if you had signed in at the hub's front door or allowed a cookie to be set in your browser, the scheduler would already know who you are and will have given you the option of a "template" based on the last event you scheduled. After guessing the venue and time of day, the only thing left for you to enter would be the date and the memo.

Popular venues might benefit from a "venue manager" - a feature of our dream hub that simply acts as a calendar dedicated to a single venue. An event coordinator can use it to see who else is using the venue and when, so that he or she can schedule their event around the other users' needs. I admit that the value of the manager would be compromised if not everyone who used that venue knew of, or even respected the authority of the hub.

The natural parallel to the venue manager would be the attendance manager, which would keep track of people who attended a particular event. It'd work like this: A visitor to the hub sees an event scheduled that he'd like to attend, so he clicks on a button to sign up for it. Now, whenever the coordinator of that event needs to change the date or time or venue, or even to cancel, those who signed up for the event will automatically get an e-mail to let them know. They'd also receive a reminder 24 hours before the event is due to start.

Other attendees would be able to see who else is going to the event as well, but the attendance manager should let people sign up privately if they wanted - giving them the benefits of the e-mail alerts, but the privacy of not being listed as an attendee.

The last obvious parallel is the itinerary manager. Here, visitors can check off all the events they want to attend. Then, after clicking on a "View My Itinerary" link somewhere, they can see a list of everything in a layout that's ready to print. The display would be compact but still list what, when and where for each event. This itinerary manager would also warn you of any scheduling conflicts - both clear and fuzzy ones. For example, you might have signed up for an event in New York for October 3^rd at 6pm, to end at 8. But then also signed up for an event in San Jose on the same day that starts at 9pm. Even considering the 3 hour time-zone difference, it's extremely unlikely that you could make it all the way across the continent in 4 hours.

Now here's the real kicker: It should be trivial for the server at the hub to also save that custom itinerary in CSV (Comma Separated Value) format that the visitor can download and which is ready to import into any of the major OS/2 calendar programs such as Lotus Organizer, Relish, StarOffice, IBM Works and ExCal.

There would be a few limits to all of these just like there are limits for the agents. First of all, each person would only be able to sign up for a certain number of events, perhaps ten, in order to stop the server from being overloaded by trivial requests and too many e-mail reminders to send out.

How To Profit From This

Far be it for me to suggest that all of the above should be provided out of generosity, indeed, there's a few easy and obvious ways of making money from it.

First of all, charge for removing the limits. As I've described, it'd be smart to put limits on the use of the agents and the calendar because both make use of CPU power, memory and bandwidth with all that searching and e-mail notifying going on. That costs money every time those resources have to be upgraded. So if the visitor wants these limits removed it's not unreasonable to ask him to help pay for that upgrade the server will eventually need because of it. These "premium" memberships should have more than one level, starting with about $10 per year, which could buy 10 agents with two year lifespans along with the right to sign up for 20 events, then all the way up to $100 per year to forget about all limits entirely.

Since visitors would have to create an account in order to use the free-level services anyway, changing those accounts to premium levels would just be a tweak to a record in a database. You could give away free membership upgrades in any promotional contests you run.

Secondly, there's good old advertising. With so many e-mail notifications going out as agents meet their criteria or warn of expiration and so many event reminders being issued too, there's plenty of "impressions" that can be sold to advertisers.

It shouldn't be forgotten that a healthy profit is one of the surest signs of a healthy community and the value of the hub is related very much to the number of people who use it, not just how many gadgets it offers. When you provide something for free you'll usually get a lot of takers, giving you the crowd and all the content they generate for you. What you end up selling is not the content that you've just been given for free, but the mechanisms for dealing with that content in a useful way.

Web developers and web hosts are wanted! I'm sure that my ideas can be only a starting point or compliment for a grander service that can pull the OS/2 community together and make it act like a well oiled machine, serving both the cogs and the mechanism with mutual benefits. Join our interactive forum to expand on these and your own with others.