The future of openmoko.org hosting

[Harald Welte]

Dear community,

Given that we've just head the 10 year anniversary of shipping the Neo1973,
this also marks about the ~ 8th-9th year of inactivity in the project.

Ever since Openmoko, Inc. closed down, I've been personally covering the hosting
fees for the (single, consolidated) openmoko.org machine.  I did that in order
to keep the legacy/history alive, for those who might be interested in it.

While it was/is "only" EUR 50 per moth, it adds up.  Over the at leaset
8 years, that's at least EUR 4800.

I was happy to contribute that.  However, I don't want to continue this
kind of financial obligation for another ten years or even any
indefinite term.

Please note that the actual burden of system administration is
contribute by volunteer work from Paul Wise, which is of course much
appreciated!

So the question is in general, how to proceed here. One could

a) try to put funding on some more shoulders than just me, and continue
   with that one hosted machine as-is

b) get rid of the existing server, by the following strategy:

   * web: convert the dynamically-generated media-wiki, trac, svnweb, gitweb,
     etc. pages into static renderings that can be served from a static
     web server.  This could be done by something like a recursive wget
     through a http cache.  This would remove the need to run trac,
     mediawiki and apache mod_svn, mysql, ... - and drastically reduce
     the CPU and Memory requirements.  In the end, it would be a bunch
     of static HTML pages rendered by nginx or lighttpd somewhere on a
     virtual server or shared server.

   * lisst: migrate the single remaining active
     (community at lists.openmoko.org) to another mailman instance, such as
     lists.osmocom.org.  We could configure mailman to retain the
     list-id and simply point the MX to the osmocom.org server, i.e. do
     this without any impact on the list address or users mail filtering
     rules.

   * e-mail: discontinue e-mail services at openmoko.org (except e-mail
     forwarding).  To my knowledge, only Joerg Reisenweber is using this
     service today - and to be fair, I would kindly suggest to use a
     different imap-capable home for his e-mail after about a decade
     of using the Openmoko legacy. Sorry :)

   * svn: discontinue svn service and simply have
     * caches of the rendered html pages (for old hyperlinks to work),
     * a git conversion of the old svn tree. for svn.openmoko.org, I
       have done this and published it at
       https://github.com/openmoko/openmoko-svn

   * git: discontinue git service and simply have
     * caches of the rendered gitweb html pages (for old hyperlinks to
       work), and
     * the mirror at github.com, which I just created:
       https://github.com/openoko
     Yes, I'm fully aware that github.com is a proprietary service, and
     they can at any time take those repositories down and/or stop the
     free service.  I'm not suggesting anyone use this for active
     development projects.  But just to have a historic archive of code
     around that hasn't changed for 9 years, I think it's ok.  Running a
     git server with a kernel tree inside requires quite a bit of
     resources, and running gitweb or cgit with all the crawlers out
     there can be a major CPU/RAM/IO hog.  If we can avoid this, we
     basically eliminate the need for a separate machine for
     openmoko.org

   * USB VID/PID repository: This is so far kept in the Mediawiki, but
     I don't see a reason why this couldn't simply convert to just being
     a static CSV file that's on a http server, or a small, simple git
     repository with that CSV file inside.

Any comments/ideas/suggestions/complants?  I'm all-in for moving
towards 'b'.  Next to the fact of basically reducing our hosting
requirements to zero, it also has the advantage that we don't have to
worry about keeping trac,mediawiki,etc. installations secure and
updated.  Also, when moving to major new versions, there's always the
risk of some issues with migrating the old data, some wiki rendering
errors, etc.  - conserving the generated output saves us from all of
that.

If we go for 'b', this would include us releasing SQL dumps of the
trac, mediawiki, svn, etc. databases (probably clearing any passwords /
password hashes), so that the raw information can be restored by anyone
who has an interest to it.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)