opendms
the rules... or the intent
need to know
before you start you should understand the character of whom you're starting with
it's all in the code
we all write the code but it must conform to "the code"
don't let them get in the way
This page is important; it defines the ethos of the opendms project. When writing the content of this site the word ethos is used quite often. We tend not to say “regulations”, “precedents”, “protocols”, or words to that effect, because the carry with them the sigma of an organization setting the “rules” for those it “allows” in.
The concepts of organization and rules do not best align with the ethos (there it is again) of the opendms project. So, what does “ethos” mean? Simply put ethos is “the characteristic spirit of a culture, era, or community as manifested in its attitudes and aspirations“; and that sums opendms up to a tee.
We are a community and that community can be identified easily enough, there is a defined culture surrounding the enterprise and, most importantly, there are attitudes and aspirations (all of which have been well presented throughout the content of this site) equally discernible.
All that said though, there has to be some points of agreement within the community so all members understand the operational boundaries and precepts (and we are not going to call them rules preferring guidelines instead) at the heart of the opendms project and we present them here.
It is critical to understand that these guidelines are fluid representations of the “characteristic spirit” of the opendms experiment (and it is an experiment for sure) and may change as the community’s experience grows.
The very nature of open source flies in the face of regulations, precedents and protocols of course but the structure of the opendms project is a bit of a hybrid of mainstream open source programs so the guidelines need to be fleshed out as they do form the ethos of the enterprise.
policies, standards and processes
The following points of reference do the best they can to outline the spirit and the operational guidelines of the opendms project. Before we get to the nitty gritty we need to talk about the elephant in the room.
opendms is open source and covers all its code offering with the GNU General Public License V3.0 and the opendms offering should be considered to consist of three distinct parts;
- applications – for example Project Forward our service online booking system;
- portal – Project Terra our administration portal for the opendms applications; and,
- middleware – a layer that provides access to the opendms databases through end-points and controls session and persistent connectivity using identity authentication and authorization.
In the opendms world, all the source codes for all elements will be available under the GNU General Public Licence V3.0 and “walking skeletons” of all application templates and the administration portal will be published so third-party developers may tap into the look and fee of the opendms ecosystem and the opendms team will happily include any administration requirements for any third-party application into the portal BUT, and there has to always be a but we suppose, the portal and middleware operations will remain under the control of the opendms team and be considered “CLOSED” in that sense.
It is critical to stress this is to guarantee service provision, security and quality; it is not commercial nor will it ever be monetized. For the opendms offering to be reliable the portal and middleware MUST be under a single central control; and that is it when it comes to it.
So, the policies we hear you ask;
- opendms is not-for-profit;
- anyone may join the opendms community;
- to access the opendms open source libraries and/or the existing applications, portal and middleware community members must become dealer members;
- dealer members are charged a monthly membership fee calculated as follows – monthly membership fee = (last quarter operating costs / total dealer members);
- dealer membership fees are capped at AU$500;
- opendms will provide open accounts to dealer members to justify the last quarter operating costs;
- third-party developers are welcome to use the open source offerings of the opendms project BUT, if they bring a product to the community, must register each product under a dealer membership and keep that membership current for the life of their product;
- opendms will provide a centralized market where third-party offerings may be made and facilitate this with an on-line store;
- if a third-party developer wishes to commercialize an offering through the opendms project the GNU license applies and opendms reserves the right to disallow or remove any third-party access to any opendms resource;
- fundamental to the opendms project is the desire to build a replacement for that traditional dealership management systems (DMS) and this will be the continued goal;
- opendms will continually monitor the various cloud-based offering from all sources to find products that might be tailored into the portal and middleware and will actively encourage third-party product involvement;
- opendms is a community; dealers helping other dealers and the opendms management team will always try to attract the best people to its ranks to guarantee the very best support and development.
So to summarize, opendms is a community of like-minder dealers all wanting to get control of their IT, keep the costs to an absolute minimum whilst providing the very best in dealership management system design.
It does NOT have to make a profit nor will it be driven by or answerable to a board interested only in the bottom line. This is NOT altruistic and the founding members of the opendms project are quite happy to let their agenda be known. They want to be able to get software developed that does EXACTLY what they want and share the cost across all like-minded dealers; that is the policy in a nutshell, the rest is just a means to that end and we’d be really surprised if any “like-minded” dealer didn’t support that agenda.