As mentioned above, crowdfunding endeavours usually have three actors; the project initiator, the supporters and the moderator. In the opendms model these are identified as;

• the project initiator or initiators – the originating group of dealers who realized that the current state of information technology in their dealerships was completely unable to answer the day to day needs of their businesses and was NOT under their control;
• the supporters – dealers including, but as mentioned above, not necessarily limited to automobile, agriculture, haulage, heavy equipment, leisure, marine etc.; and,
• the moderator –  the opendms management team (the management team that works for the best interests of every community member).

We discuss elsewhere on this site the reasons behind the project initiators conceptualizing the opendms project but suffice to say, these dealers were already investing in their own information technology and working to reduce the reliance their businesses had and has on the traditional information and DMS services. They were prepared to design, develop and implement their own solutions BUT realized that without the support of all dealers to find a new way “for all dealers” their efforts were never going to be more than band-aids in a severed leg.

The question was “how do we create a community of dealers working together and guarantee its ongoing success”? It was agreed that this community had to have a small management team of hand-picked professionals being paid correctly for their expertise and that the management teams would;

• have the skills to conceptualize and design the products and services needed to create a middleware between specific applications and programs and existing cloudware (open source, freeware, shareware and commercial) solutions; 
• to be able to research and then recommend to the community which existing cloudware might be considered; 
• be responsible for managing the outsourced development of these middlewares;
• be responsible for the development of any specific applications considered core to the opendms project;
• to manage and interact with any third-party contributors that may wish to add value with products and services through the middlewares; and,
• most importantly, to be a liaison between the opendms community and any OEMs that wished to connect to their dealers using the opendms middleware.

Whilst a simplistic representation of the opendms ecosystem, this diagram helps put a picture to the words. In essence the opendms project offers any dealer access to a raft of products, expertise and support that they may struggle finding “doing it on their own”.

THE MODEL – how to make it work

opendms needs to find a number of people who have the following expertise and experience in;

• DMS design;
• the operations of information technology in a dealership-based business;
• the design of middleware components using “current” technologies;
• the implementation of application level solutions to DMS systems;

and further;

• to liaise with all players in the opendms diorama with professionalism and conviction; and,
• the vision to get ahead of the requirements of the automotive dealer in the current business world; and to stay there.

The skills required are very specialised and not going to manifest in a single person so it is expected that the opendms management team will consist of a number of people providing a cohesive solution to these requirements.

What is exciting about the opendms project is that it is building an open source community and the concept of this “openness” will extend beyond software and into a broader area of intellectual property. It is expected that the expertise and experience noted above might well be augmented by community members and a major role of the opendms management team might be the coordination of input from community members who can offer their expertise and experience and calls may be made to the community by the management team to seek just that help.

So, referring to the diagram above, the opendms management team will oversee the community assets by undertaking;

• the management of the community membership;
• the ongoing analysis of the cloudware world to keep abreast of the new offerings and how they may be used by the opendms community;
• the design, development and control of the products considered “core” to the opendms project (effectively the elements that need to be added to any cloudware to provide, ultimately, a complete DMS solution);
• the liaison with third party contributors to introduce the commercial developers and OEMs to the opendms middleware layers;
• the management of the third-party service providers involved in DMS conversion programs, training and support for the core opendms products; and,
• the task of keeping the content management systems used by the opendms project current and relevant.

THE DEALERSHIP – tapping into the project

To join the community costs nothing, you can tap into the support structures, source library and community forums with a simple community registration (and opendms will never share its membership list with anyone under any circumstances).

In the diagram below we’ll assume a given dealer group has automobile, agricultural and haulage dealerships but it extends to any dealership model.

The dealer group would create a community registration and, once complete, an X-Secret-Key would be generated and returned to the dealer group.

The dealer group would then create dealership memberships for the various dealerships within the group and each of these dealer memberships would attract a X-Access-Key (uniquely identifying the specific dealership within the dealer group) and a monthly fee.