Latest OpenQabal News
I'm sure most everyone is assuming that OpenQabal is dead. That would be a reasonable assumption given the lack of activity on my part for the past while. And it may even be true, for a certain value of "dead" and a certain value of "OpenQabal." Certainly since the last time I was heavily engaged in this project, the world around us has changed, and context and assumptions have changed. To everyone who wanted a decentralized, federated, open-source social-networking platform 2 years ago, I apologize... I let myself get distracted by other concerns and let this languish.This is doubly sad given the recent burst of interest in that very space (see: Diaspora), after the Facebook's Gone Rogue bit; but things are what they are and there's no use crying over spilt milk. So, the future then... As I said almost a year ago, the goal - in my mind - had already changed to being more about APIs for building "social applications." I believe that is still the case, and that is still the direction that I'll be pursuing with code I write in the near future. There is another subtle (or not so subtle) shift in focus as well... More than before, my intent is to focus on APIs, interfaces and tools for building socially aware applications in an enterprise context. As much as I hate buzzwords and labels, I'd say the goal is a Enterprise 2.0 suite. As my current interests have moved heavily in the area of social ranking / voting, collaborative filtering, tagging, etc., I've started coding up a front-end to work with those techniques. As that evolves, some of the same APIs that were part of the OpenQabal vision 2 years ago will begin to evolve again. Some new things may appear, some old things may get dropped, as I explore some ideas about how all of this will work. At any rate, there *will* be new work coming out of the OpenQabal project, it just might not be what anybody thought it would be before. Some things I know I'll be doing:
- The newest code I'm writing is in Groovy / Grails. Any user facing / UI stuff I work on in the near-term will probably be in Grails. Backend APIs will *probably* be plain Java, but don't rule out seeing Scala or Clojure show up somewhere. And depending on what kind of stuff we wind up needing, some C++, Python or Erlang or "other" could wind up in the mix as well.
- The new code will be going up on GitHub soon. Sometime after that, the existing code probably will as well (this is assuming that the existing code base is worth keeping around). I'm convinced that DVCSs are the way forward, but if a convenient way can be found to do it, we can mirror the code into java.net svn as well.
- I've been working with Hudson at my day job, and realize I like it better than Cruise-Control. I'll see about getting a VM setup somewhere, to host Hudson, Bugzilla, etc. Having that stuff running on an old box in my home office, sitting on a cable modem, is not ideal.
- Soon I'll see about getting an instance of Agilefant, Ice Scrum or XPlanner+ setup for managing the backlog
- At some point, I will take another stab at making an actual "road map" and some documentation that illustrates what it is that I'm on about here. I know I haven't done a very good job of articulating what the goal of this project was in the past (that's because *I* didn't really know either) and when I have articulated something, I've diverged from that more than once. Such are the perils of an exploratory approach. It will all become clearer eventually. No, really...