We recently attended EMEA IOUC Summit 2013 in Ghent, Belgium, last spring (EMEA IOUC stands for International Oracle User Group Community from Europe, Middle East and Africa). This meeting was very important because that’s an opportunity that user group leaders have to share what really works and what actually doesn’t work when managing their community.
After acquiring Sun Microsystems, Oracle included Java™ User Groups (JUGs) in IOUC and many JUGs within EMEA were invited to attend the summit. According to some veterans, the gathering at the beginning was like water and oil. Now, they’re much more in line, but there is still a rich diversity in terms of organisation and culture. That’s a real cultural mix.
JUGs are used to be independent and lean. They are supported not only by Oracle, but also by several players, such as RedHat, IBM, Google and others. They are less attached to products and more attached to solutions, which is inherited from the spirit of Java™: “Write once, run anywhere”. Oracle does respect that, continuing as the main JUG supporter out there and avoiding interfering in JUG’s organisation. The coordination of community initiatives is always done with JUG leaders, who contribute with ideas and actions through their respective user groups.
Recently, Oracle and community leaders realised that the process of creating new JUGs was outdated. Ironically, the process was heavy and difficult to manage, not fitting in Jug’s philosophy. Perhaps, it explains why it didn’t really worked. Bruno Souza, an active Java evangelist, was involved since the beginning and gave further details about that:
“Java.net was always structured to be a ‘code’ site, and because of that, it has the concept of project approval and the incubator. Project approval was the step where an admin of a java.net community would consider relating a project to their community (for example, the Desktop community would probably not accept a server side, JEE project). A JUG’s project approval was very loose. If someone said their project was a JUG, we simply took their word for it. The project then would be accepted into the ‘incubator’, that was a staging area, were the project could start, and be clearly labeled as ‘incubating’. To graduate from the incubator, we had a series of steps, that have evolved over time to include the JUGs Map and other basic requirements.”
He concluded saying:
“Of course, as time went by, some of this got lost, some of the approval process started to be done by java.net support staff and not by the JUG leaders, many JUGs never completed the incubator steps (we have around 40 JUGs on the incubator right now), and many JUGs don’t even know about any of that.”
Then Oracle started a discussion with some community leaders (Bruno Souza, John Yeary, Nichole Scott, Tonya Moore, Sonya Barry and Frank Nikola) about what is working and what is not working. They came out with the following process to create and maintain JUGs:
- A prospective JUG leader joins Java.net and requests a project with the proposed JUG name.
- At creation, the project owner receives an automated email asking him(er) to contact the community manager at Java.net to request that the new JUG project be made public.
- The JUG leader can choose between Java.net, their own hosting provider, a social network or any other online service to host JUG’s online content. In case it is hosted elsewhere, the leader just have to add the external link in its Java.net project profile. Actually, the only reason Java.net has to create an actual project is to prevent name collisions and keep the database consistent. The project itself can be entirely empty.
- Java.net asks for a KML file to add the location of the JUG in the map, in case it hasn’t been supplied yet.
- Java.net’s team adds the JUG to the map and make the JUG’s project public, moving it directly to the main JUG community.
Paired with this, Java.net will start an annual review of JUGs. The process works this way:
- Once a year, people listed as “admin” in JUGs’ projects receive an email asking if they’re still active and if Java.net needs to update any information on the site. The reply can be as simple as “yes, we’re still active, no changes”.
- If Java.net doesn’t receive a positive reply within 30 days, they will follow up with a bit of a research to see if they can find the JUG in question. Perhaps the leadership has changed or a URL has been updated.
- Java.net tries a second contact using any new information they have. If necessary, they translate the message to the local language.
- If Java.net doesn’t receive a response to the second inquiry within 30 days, then they send the final notice.
- At 90 days without a reply, Java.net moves the JUG project to an archive/inactive state and removes the marker from the map.
- A quick note is sent to the leaders’ list, letting them know which JUG has been retired.
Any retired JUG can be reactivated at any time, by going though the first process described above.
The intention, as pointed out by Mattias Karlsson, JFokus organiser, is to be “generous and don’t set boundaries if anyone wants to start a JUG.”. Sonya Barry, director of community Infrastructure at Oracle, believes the goal is “to grow the community, and make it easier to join and more inclusive”.
These processes started running in March 2013, too soon to figure out what is coming out of them. They invite further discussions a year from now to see how effective they are. But it is already good news to have established and transparent procedures. Congratulations for the team involved!