[Parl-devel] global vs. local community building

[Jonas Smedegaard]

DebianParl is globally oriented with its ties to Debian, but each 
deployment is likely to be locally oriented - concretely the [Greens/EFA 
pilot] tied to [EPFSUG].

[Greens/EFA pilot]: https://wiki.debian.org/DebianParl/GreensEFA
  "Pilot project about trusted email"

[EPFSUG]: http://epfsug.eu/
  "European Parliament Free Software User Group"

How do we balance that?

[Skolelinux] has some similarities with DebianParl - aim was global but 
initially most activities - both development and deployments - happened 
in Norway.  When later activities mushroomed in other countries, ties to 
the local Norwegian community was stronger than those to Debian, and for 
several years both development and usage were largely split into 
Norwegian and German communities. The split was - to some extend - 
caused by language barrier (especially for users) and difference in 
interests (for which partly [I am to blame]), but too many lists for too 
little crowd and leaders' [sloppy nursing] played a part too, and was 
only cleaned up very late, by the always painful process of merging 
lists.

[Skolelinux]: http://www.skolelinux.org/
  "complete and free “out of the box” software solution for schools"

[I am to blame]: I convinced Kurt, the leader of Skolelinux Germany, to 
_not_ use Skolelinux as-is for a large deployment in Rheinland-Pfalz, 
but instead try reimplement it more tightly integrated with Debian.  
Reality turned complex, and we didn't reach intended goal, as indicated 
in this summary of a later reflection by Kurt: 
https://blogs.fsfe.org/guido/2012/11/skolelinux-pilot-in-rhineland-palatinate-lessons-learned/

[sloppy nursing]: https://lists.debian.org/debian-edu/2005/05/msg00017.html
  "Skolelinux leaders and me discussing which lists to use when"


I would prefer to learn from that, by identifying each activity as 
either global or local, and actively nurse it accordingly.

Concretely the following issues have come up recently that I have 
noticed as related to this global-local conflict:

 * hosting of resources (e.g. mailinglists) for a deployment
 * branding of deployed systems


Hosting
-------

DebianParl should ideally - being a Debian sub-project - be hosted 
within Debian.

Concretely for Greens/EFA pilot there is an issue yet unresolved about 
email address mangling inside the European Parliament, raising the 
question if better to have EPFSUG host a list instead.  Short-term that 
might work fine (depending on stability of those resources), but would 
cause participants of that deployment to be treated as local, not 
global: Users of the Greens/EFA pilot will then hangout at a list 
unlikely to grow beyond users at the European Parliament.

I find it quite important, for the project in general but also 
concretely for this specific pilot, that users get the largest possible 
potential for synergy - by trying hard(er) to keep global things global.


Branding
--------

Should EPFSUG brand laptops deployed in "their hood"?  Should Debian?  
Should the deployment "host" (e.g. Greens/EFA)?

Ideally I guess all of them should be given the offer of promotion: 
Credit for contribution is commonly the only form of "payment" in 
volunteer projects like this, and this branding is clearly a form of 
crediting participation.

There's a technical issue, however: Debian is Free Software, so in 
principle is easy to adapt e.g. for branding purposes, but currently 
that comes at a high cost: Debian has no space for rebranding as-is, 
requiring some form of "hacking on top" - i.e. adaptions unsupported by 
Debian and therefore risky for maintenance.

Deploying e.g. laptops directly to users, with no support staff to 
handle quirks, has a _very_ high demand for smooth maintenance.

Concretely for the Greens/EFA pilot, I therefore find it wise to do 
little if any branding of the software - and instead make stickers to 
put on the outside case of deployed laptops.

Siri and I are working on making Debian brandable in a maintainable way.  
Not hardcoded (like Skolelinux with its debian-edu-artwork package) but 
flexible enough for each deployment to dictate its choice of branding 
(within some well-defined limitations).  That work takes time, though - 
one or more years - before it will be available in stable Debian.


Thoughts? Comments?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/parl-devel/attachments/20140117/1b293bb9/attachment.sig>