[OpenFontLibrary] Why Drupal?

[eric at authoritism.net]

Hi Ron,
great you’re here.

I guess we also need to look at what we wan’t to get out of v3 no?

What I would like, I can imagine to be possible with Drupal, or any decent
extendible CMF. Probably with Aiki too though I’ve never seen it up
close.

I think it would be good to move away from the CMS paradigm where the
content is stored inside the system itself. I would strongly favour to
*not* have font files in the cms, but rather have the website be a
front-end to a font-hosting service. Font-hosting as, hosting the source
code for open source fonts in a structured manner as Nicolas is
researching, in a proper distributed version control system. This way you
don’t lock up your font data in yet another system.

With DVCS you get the whole development collaboration model of software
development for free. Power users can bypass the web-interface altogether.
Power of distributed, OFLB fonts could also be clones of repositories
elsewhere. The web-based interface works just like a regular website, but
instead of interfacing with a database, it interfaces with the repositories
behind the scenes. Say a user uploads a new font, behind the scenes a new
repository is being made but the user need not concern with the
technicalities. ‘Remixing’ a font creates a fork etcetera

I see Drupal already has something like
http://drupal.org/project/versioncontrol

On Fri, 02 Jul 2010 20:26:56 -0400, Ron Williams <ron at lithicmedia.com>
wrote:
> Hello,
> I'm Ron and I was contacted by Dave after submitting an error report. In 
> response I proposed moving the site over to Drupal and based on the 
> discussion with Dave, most of the site functionality can be built using 
> existing modules with configuration. I won't debate any about this, but 
> I will interject a few clarifications.
> 
> For one, I don't think I'd refer to it as Drupal fanboyism; more like 
> the current system doesn't work and rebuilding it with a system whose 
> members support FOSS and have already adapted the system to many 
> different project types is a good direction to go. Once released I 
> believe many Drupal developers will use and contribute back (through 
> volunteer development and donations) to this project.
> 
> Drupal does have many modules and as mentioned quite a few are 
> abandoned. Just because there are abandoned modules doesn't mean they 
> weren't migrated to something better. Take for example the fckeditor and 
> tinymce modules, with one swoop of the wysiwyg api module, they became 
> the underdog and will most likely be phased out because their 
> functionality is now part of another module. Another reason for modules 
> going away is the migration to more CCK/Views based site implementations 
> for long term maintenance. If all modules were doing is storing specific 
> data in 4.7, but now they've gone away since it's better to do it with 
> CCK and then modify the data on output.
> 
> Regarding a dedicated server being required, I can assure you that is 
> wrong. I have personally rolled out sites on Godaddy's shared servers, 
> Rackspace cloud sites, and (of course) dedicated servers. There are 
> benefits to having a dedicated server, but it's far from required. 
> Drupal is in use on a variety of high and low traffic sites, it recently 
> was used for Earth Day 2010 which was linked from the Google home page. 
> In that case there were multiple servers involved, but you'd expect that 
> with any system.