Uniting the JUGs Under the IOUC
The IOUC is basically a leadership forum for user groups that provides a unified community voice to interact with Oracle. It has committees such as the Support Quality Committee which alerts Oracle to issues and concerns, and reports back to their members. There's also the Product Development Committee, which provides a forum for sharing information about Oracle products under development. Other global IOUC committees address education, product localization, and business practices. Each region has assigned user group relationship managers. According to the proposal, "Oracle has also identified many local points-of-contact within each region to work with user groups, enabling regular communication regionally and globally."
The takeaway that many JUG community members saw in this proposal was the streamlined, unified voice that Oracle wants to create from the multitude of JUGs worldwide. In joining the IOUC, Oracle was very clear that JUGs would become part of a body that, "represents our trusted advisors… a powerful vehicle for all user groups."
Jeb Dasteel, a Senior VP and Chief Customer Officer at Oracle, presented three different models that JUGs would fall into. Each JUG is expected to fall under one of these categories without exception. For gray-area cases, Oracle will collaborate with them and see what works. In the conference call, Oracle said they will publish a list sometime on the iouc.org site that shows which models each JUG fits into. Oracle is currently setting up a more robust infrastructure for online access.
INTERNATIONAL ORACLE USER GROUP COMMUNITY (IOUC):
- A community of user group leaders working as one global entity to communicate with Oracle on many levels.
- The members share information on leadership and best practices and identify issues of concern.
- All members participate in an online collaborative workspace for coordination and unified communication with Oracle.
- There are monthly calls and a yearly meeting at Oracle.
- Anybody can participate in committiees
- Members meet regularly with Oracle to discuss issues of importance to the user groups - both at the regional and global level.
- Participate in IOUC committees as appropriate and encourage members to learn about and contribute to committees.
- Groups cannot be run by Oracle employees.
MODEL 1 - LARGE GROUPS WITH PHYSICAL MEETINGS AND GOVERNING BODY:
- Legal entities, independent of Oracle, with elected board of governing body.
- May support sub-groups throughout a region, which are also legal entities.
- Represent thousands of members to Oracle and engage with a regional Oracle relationship manager.
- Groups may be national or regional, focused on applications, technology or industry.
- Generally focused on specific Oracle products and services.
- National and regional groups that are legal entities have Oracle points-of-contact, or liaisons, assigned.
- May support special interest groups focused on a singular product or feature of a product.
- Do not allow duplicate groups with a given location (generally city).
- Follow rules of engagement with Oracle (sponsorship of meetings, sharing of attendee information, etc.).
- Host regional meetings / national conferences and invite Oracle to present.
- Have a strong web environment for their members to share ideas, solutions, papers, etc.
- Submit requests for product enhancements and provide feedback across Oracle's business.
- Groups work together to provide session content for Oracle OpenWorld.
- Work cooperatively to incorporate groups from acquired companies where possible.
- Work together at the regional and national level to co-locate conferences and meetings.
- Promote the value proposition of user groups to a wider audience.
MODEL 2 - MEDIUM TO LARGE SIZE GROUPS WITH PHYSICAL MEETINGS AND ONLINE PRESENCE:
- Participate in online user groups and host regularly scheduled physical meetings regionally.
- Larger groups often host annual conferences; May be assigned an Oracle relationship manager.
- Groups may request to host meetings at an Oracle facility based on availability of local Oracle contact and the facility.
- Generally need 12 weeks notice, list of attendees and presence of the Oracle host at the meeting.
- Groups do not have to affiliate with one another - may be many groups in one city or each region.
- User group leaders in this model may be invited to IOUC activities.
MODEL 3 - ANY SIZE GROUPS WITH MOST INTERACTION ONLINE:
- Primary interaction and collaboration occur online (Online community: mix.oracle.com).
- Oracle technologists engage online and via email.
- No services, just the community experience - groups might form and break up at will.
- Open to anyone interested in technology (generally not specific products).
- Focus is on sharing ideas, best practices and problem solving.
- Groups do not have to affiliate with one another - there may be many groups in one city or location.
- Do not have to be legal entities. May or may not have elected board or governing body.
Most of the questions discussed in the conference call had to do with the differences between groups, especially between model 1 and 2. Model 1 JUGs are large, legal entities with governance, while model 2 JUGs could be just as large, but they aren't legal entities. You can follow the additional conference calls next week if they are transcribed on the JUG mailing list like they were this week. You can find rough notes of this week's conference call on the JUG mailing list.
Fabrizio Gianneschi gives us a pretty good impression of what this announcement means for the Java community:
"What I'm reading there is only "if you want a certain level of support, you've to/should be organized in one of the following models".
More than a tiering it seems like a business contract, or a method to classify the groups, which honestly -to me- appears reasonable enough under Oracle's point of view, because bigger and more organized JUGs deserve more attention than others. That's fair. On the other hand, it could stimulate smaller groups to grow in order to get more support from Oracle.
So, for now, I don't see anything bad on it.
We know that the JUGs community is a living blob: how hard is to count us, to define what a "JUG member" is... Even after the consolidation of the mentioned models nothing will prevent a bunch of guys to create a JUG, define their rules, start running it and become part of our independent community, without asking anything to anyone. That's the key point to defend, for me."