Introducing the Gazebo Hub Organization at Github

Introduction: "Where'd my SourceForge Content Go?"

This past weekend, when I attempted to log in to one of my SourceForge projects to add an item to the project's web log, I had the unfortunate opportunity to observe that my SourceForge account was, at that time, disabled - with no previous notice, to me, to even begin to explain the cause of that unexpected unavailability. SourceForge as a web site was still operating and hosting projects, however I could not access any of my own, owned content.

Moreover, the projects I've created here at SourceForge were no longer available - no source code, no wiki or blog content, no web content, "all gone". After contacting SourceForge support that weekend, for clarification about the issue, I received an email during their normal business hours, indicating that the change resulting my projects being accidentally deleted and my SourceForge account accidentally disabled, it was during a recent batch of anti-spam work, and that those had been restored. At the time when I first observed the peculiar situation, it then had become, to me, an opportunity to develop an idea for hosting those projects elsewhere. Though I would've been at a loss for the lack of synchronization between the project wikis and weblog and, secondly, my own filesystem, but I would've at least been able to push my own local repository of files, to push that to an alternate host, such as GitHub

Fortunately, my account and my projects have been restored, here at SourceForge - presumably, from backups. It being a free service overall, I've no long complaints about the issue, though it certainly startled me, and has affected my point of view with regards to the (new to me) question of how well I may be able to trust that these projects will be consistently available, when hosted entirely at SourceForge. I would like to continue with my project-logistical considerations from this weekend, then, as far as the projects maintaining any perhaps more centralized control - though developing a more distributed service model - but to keep the projects' content and resources consistently available, namely.

Ultimately, for some purposes of resource design and structure, I may like to do self-hosting for the projects' web content, so far as may be feasible, eventually, in a self-hosted Java web portal framework, However, considering the demands that simply the management of such a framework may impose on my time and my own personal, financial resources, I think it's just as wise to continue to outsource any bandwidth-limiting features - such as hosting of project deliverables and file content, as wiki content, and as source code repositories - to continue to outsource those services, in these open source projects . So inasmuch as the SourceForge hosting may at least provide a typically consistent availability for the resources of the respective projects, may I plan on those projects continuing to make use of certain services typically available via SourceForge - such as, project web hosting, and 'ticket' hosting for those projects - and presently, also project blog hosting. Granted, even those services can be migrated elsewhere. Considering the unfortunate nature of that interruption in the projects' availability, over the weekend, I may rather prefer to migrate the whole lot of it to other service providers.

Inasmuch, tonight I've thought that it may be wise to continue with the plan of developing a more decentralized model for hosting those projects - including Gazebo Hub, Project Lupine, and the number of ontology-centric projects I've created (namely, Athtology, ArsDB, SpaceOWL, Project Ivo, and Project Clyde). This decision for developing a more decentralized hosting model - and, inasmuch, a more centralized and more focused logistical model - the decision is affected not only after the interruption in the projects' availability, and my own user account's availability, this past weekend here at SourceForge. Additionally, there is the opportunity of there being some additional features available, via other hosting options.

Considering that I do not wish to see these projects targeted with any further, aggressive anti-spam policies, I plan on, firstly, moving the central source repository hosting and wiki hosting for these projects over to Github. I might, secondly, move the web-log hosting for those projects into Blogger, to rather begin to develop those projects moreso without their respective woodsheds here at Sourceforge - perhaps then developing a more active, dynamic style of each of the projects.

Migration Phase: Migrating the Wikis

When the project's wikis would be hosted at GitHub, then those projects would be using GitHub's own Gollum wiki service. Inasmuch, those wikis should be able to use a wider range of syntaxes, in regards to the wiki content, in addition to the basic Markdown syntax supported mutually (with respective extensions) by SourceForge's Allura system and GitHub's Gollum, both - as well as additional features available via Gollum, such as header and footer files, syntax highlighting, as well as a more content-centric model for additional content files - something other than Allura's "Additional content as comment attachment" model, presently. Simply, GitHub's Gollum presents a reasonably more sophisticated wiki interface, and it can be synchronized to the local filesystem via Git - as well as being structurally manageable via Git, such as for content branches and merging.

Migration Phase: Migrating the Source Code

The source code migration would be as simple as as some work with Git remote, branch, and push commands, to create a full mirror at Github, then to delete the secondary repositories here at SourceForge - furthermore adding links to the projects' navigation bars, to ensure that users will be able to find the source code from the Sourceforge project pages for the respective projects.

Migration Phase: Migrating the Weblogs

Google's Blogger service offers a broad range of features for weblog creation and management. In that added complexity, it would seem that there may be more opportunities to become simply side-tracked from the development of simple, descriptive content. However, considering that those content creation and content management features may be used and used effectually, in developing what may then be a sort of dynamic web log content creation model, certainly those features are nothing of a liability to the weblog author. Considering that Blogger may migrate just as well into a Portal/Portlets framework, it would seem that these projects should migrate their respective weblogs into Blogger.

Post Migration: File Release

With the projects' respective source code repositories then being hosted at Github, the projects may then make use of Github's Releases feature. That feature, at Github, may serve to add a significant sense of focus in regards to development and delivery of project software resources, within the projects' respective workflows. Additionally, it would seem to be relevant in regards to developing formal process models within the respective projects - such as in reference to Scrum process.

Unresolved: Migrating the Web Content

The Gazebo Hub and SpaceOWL projects have both published a limited number of ordinary web content files - in a limited sense, web sites. Those web sites could be hosted, alternately, via GitHub pages though that would serve to impose some limits on the types of content and services that could ultimately be used in those web sites - namely, GitHub pages would not support PHP or databases. Granted, those web sites don't presently use PHP or datbases, though the matter occurs to mind as in consideration of typical web development practice.

Summary: Coffee and a Smoke

...