Ah, TSS… so much potential, unused.
I had big plans for TheServerSide. I’d like to let you in on some of them, because I don’t have time to make them happen all by my lonesome, and I hate the idea of letting what could have been a good set of ideas disappear if I were to, say, get hit by a bus.
I’m a big believer in cutting losses.
The way I see TheServerSide (or sites like it): it’s a huge stream of information. Each element in the stream contains a topology, where there are two main categorizations for each element, and a set of (potentially) unrelated tags.
The main categorizations were by element type (article, newspost, cartoon, review, multimedia) and by architectural position (persistence, presentation, development, and architecture). These are used as a subtractive filter, so you could say “I only want to see articles,” or “I only want to see persistence,” or a combination: “I only want to see articles on persistence.”
The additional tags could be whatever was appropriate. They’d be used more for searches than for restriction of content.
A late idea – maybe from 2007 – was that you could add a third layer, for language, so you’d be able to say “show me all the persistence articles that use ruby.” TheServerSide was Java, of course, but I don’t think it’s reasonable to look at every project as being 100% Java. It’s appropriate to think of the right tools for each project; I don’t see why PHP would be horribly offtopic, especially if readers could say “I don’t want to see PHP.”
For TechTarget, which has a stable of sites, you could see a SOA site using that one stream of information and only presenting SOA topics; same for .NET or any other similarly focused site. I saw TheServerSide as being more general, so I figured it would use everything the stream had to offer.
Implementation note: JCR would be perfect for this sort of thing, and it’d be really easy to code and it’d run very quickly. (Proof: see InfoQ.)
Now, back to presentation: One of the things I always liked about TSS was that it put its money where its mouth was. TSS used Java to do everything, for better or for worse; recent incarnations used Tapestry plus Jive, which may or may not be an optimal combination… but what if users could do their own interfaces?
Imagine a front end written in Struts 1, using the common backend… and another front end with Struts 2, and another with JSF, and another with Wicket, and another with GWT… and the people who know each technology would have the opportunity to write and maintain their chosen implementation.
It’d be a perfect demonstration of each framework under load; users could select which interface they wanted by using a domain name (struts1.theserverside.com, jsf.theserverside.com, php.theserverside.com) and look at how the system was implemented; a small and trusted group of architects and coders could make sure the interface didn’t violate various restrictions (namely, those restrictions that prevented ad delivery, which is the profit vector for a site like TSS.)
Of course, this would mean that TSS would have to do something readers asked about over and over again… it’d have to make its source available. Horrors, right? After all, it’s a community site that talks about open source all the time, and thus it makes sense to me that the community it serves would be able to contribute back to it.
Another unrelated idea was actually co-opted by DZone; the DZone links page is very close to the sort of thing I wanted TSS to have as a feature. I would, however, like to add that I had a machine learning approach; I wanted readers to not only be able to vote for items, but for the system to learn what people liked, so it could make recommendations even before readers rated content.
I’d have loved to see all of this put in somehow; sadly, the people at TechTarget never had the time to do any of it, or the inclination; if you read what I wrote carefully, you can see that I was trying to give the community the means to do all of it.
