[osol-mktg] Community Consolidation -- Marketing & UGs

[Bruno F. Souza]

On 06/04/2007, at 00:40, Jim Grisanzio wrote:

>
>
> Stephen Hahn wrote On 04/06/07 11:43,:
>>
>>   *cough* Projects *cough*
>>   My name suggestion (really Simon's from a year ago or so):   
>> Advocates.
>>   - Stephen
>
>
>
> Oh, cool, I like that. Ok. :) I'm an idiot.
>
> And we can do that right now without any merger or need to propose  
> new site changes, and it solves the immediate structural problem  
> with the UG community. UGs can still have their own spaces/lists  
> and still communicate across groups via ug-discuss. Each existing  
> user group becomes a project, and new user groups can go through  
> the same project proposal process currently in place.
>


Ok, I'm an idiot too :-)
I'm so used to the way we structured java.net Java User Groups, that  
I didn't notice it was being done different here...
So, java.net has the same issue that we have here: the site  
infrastructure was created to host software projects, not really  
"communities". Let me describe the way we "solved" that for UG on  
java.net, this may be a good starting point for the UG community for  
OpenSolaris.

- there is a JUGs Community: this is where JUG leaders join and  
discuss joint efforts. The JUGs Community has a few mailing lists  
that are targeted for JUG leaders to discuss things, and hosts very  
few content by itself. It is more like a discussion on how each  
leader can make his own group more effective by learning from others.

- each JUG can request a project on java.net, that will go "under"  
the JUGs Community. The project hosts the JUG mailing lists, files,  
etc. Some JUGs even have _software_ projects, that are hosted as sub- 
projects of their JUG. One important thing is that in java.net  
project requests are not a "community wide" thing. So, JUGs request  
projects for the JGs Community, and that gets approved by JUG  
Community Leaders, that are elected by the JUG Leaders. So, when a  
JUG request a project, it can be approved right away (it is actually  
put under the incubator, and when JUGs comply with a few  
requirements, like creating a web page, etc they are "graduated" to  
become a project under the JUGs Community). It does not need to go  
trough any "community wide" approval or vote.

- The JUGs Community on java.net recognizes that JUGs may be part of  
the community even if they don't ever request a project in it. So,  
the JUGs listing lists all JUGs that want to be listed, no matter  
where they host their members. And the JUGs Community is still the  
place for the JUG leaders to discuss, even when their JUGs don't  
share the java.net infrastructure. Some JUGs even don't trust Sun  
enough to request their members to register in java.net (since  
java.net is a Sun infrastructure). But they are part of the JUGs  
Community nonetheless.

- JUGs then have their own java.net space, that this is all their  
members really see. Also, more organized JUGs also have their own  
(outside java.net) web space. Since JUG members are Java developers  
that care about the technology and learning how to use, etc, they can  
do this under each JUG, even if they never care for the "JUGs  
Community" itself. Most developers don't anyway.

- This may look like "dividing" the community, but it is actually  
empowering the local communities. UGs will bring local developers  
close together, and support their activities. Developers will also  
participate on the larger community by themselves (like joining other  
forums and projects), but when they have a place they can come to to  
discuss and defend their local interests, it is easier to get their  
companies involved, they get more attention, etc. Without UGs, we  
loose the capillarity, and all needs to be done "over the web", where  
it is harder to relate to each other. And UGs will always be a  
division, because each will do pretty much the same thing of every  
other, but with a local focus. This is actually a good thing :-)

- the main problem with a "JUG as a project" approach is that usually  
UGs don't "get it" right away. They will create the project, and not  
know what to do with it, because projects are focused on code  
activities, not really on what UGs do (presentations, events,  
discussions). This is a flaw on the infrastructure used, that most  
JUGs will try to compensate by having parallel lives on sites like  
Yahoo, or hosting their own services.

Hope those past experiences with JUGs can help structure the  
OpenSolaris UGs Community.

Bruno.

> I like Advocates, too. We now have three possible names: Advocates,  
> Evangelism, Outreach. I see little consensus for a merger, but if  
> we can solve the structural problem with the UG community that  
> would go a long way to making that community more effective.
>
> I say we do it. Other comments?
>
> Jim
>
>
>
>
>
> _______________________________________________
> opensolaris-mktg mailing list
> opensolaris-mktg at opensolaris.org

Bruno.
______________________________________________________________________
Bruno Peres Ferreira de Souza                         Brazil's JavaMan
http://www.javaman.com.br                      bruno at javaman.com.br
         if I fail, if I succeed, at least I live as I believe