opendms
find out why this project was started; what the commitment is and who made it
just how far does this project want to go; what are its goals and aspirations
explore the path the project will take; how will it unfold
opendms is the child of a handful of like-minded Australian automotive professional with a vision for how their businesses have to present themselves in the changing market-place of the 21st century. More so, it is born with the realization that nothing in the tradition automotive IT business model, a business model dealers had little or no control over, is capable of supporting any of it.
Every day exciting new products and services are appearing in the IT world to provide businesses with the tools needed to work in the new “information market-space” but the problem facing dealers is how to get it all to work; who to turn to for help?
It is obvious that the traditional IT infrastructures designed and controlled by the various dealership management system (DMS) and independent third-party providers (existing providers) are, if not incapable of, struggling to answer the needs of a modern dealership.
Existing providers seem to believe that their systems are more than adequate whilst they continue to represent the single largest administration expense to the dealer and do little, or nothing, to answer these new pressures of business.
These existing providers are overseeing administration systems that, at best are 10 to 15 years old and, in some notable cases, were designed and introduced in the 1970s and have seen little or no change since.
The opendms team believes that dealers need to get control of this but just saying there is a problem means nothing; doing something about it is what matters.
The issue of scope is always interesting. The Chinese philosopher Tao Te Ching tells us “a journey of a thousand miles begins with a single step” and when one considers the structure of a traditional dealership management system (DMS), the idea of building a DMS from scratch seems daunting; a fact the existing DMS providers rely to keep new entrants out of play and the key to understanding the scope of the opendms project is to consider what a “traditional” DMS is.
Because of their maturity (read age), traditional DMS offerings were built in an age of “big system” development. What this means is that the programs (after all a DMS is just a program; consider it an app if you like) and the data are tightly bound and the elements of the program are contained within a single production layer.
It matters not whether the shell is Unix or Windows the effect is the same. Traditionally, DMS programs are tightly structured and bound inexorably to their data. As features are added they are incorporated into this structure and can not work outside it.
Dealers using traditional DMS systems see the characteristics of this type of big system design every time there is a patch, database upgrade or version release. The system is completely replaced and, quite often, weeks or months of broken functionality are gone through waiting for a new patch to fix what the last patch broke (and pray that something else doesn’t break in the process).
So, when considering the scope of the opendms project, the opendms team (team) realized that to just go and write a DMS from scratch would be foolhardy at best and lunacy in reality; but only if we were bound to the big system model.
This is discussed in depth in the design sections of this site but we’ll introduce the concept here.
In 2020, there are many wonderful solutions available to businesses to perform many varied tasks. Many of them are open source and, if not free, their commercialization sees monthly costs under $100-$150, for example;
just to mention a few. The real reason for putting a list up was to touch on what opendms is all about. There are products available in the cloudware ecosystem that could do everything a DMS needs to do and, if not specifically what a DMS needs, all have software developer tool-kits (SDKs) that would allow skilled system designers and developers to meld them to appear a seamless solution.
Imagine if the Zoho group of product (and you guessed it, Zoho has an accounting module) was able to do 70% of what a dealer needs and the opendms group was able to direct and control the development of a series of open source front-end and back-end modules that could sit over the top of the Zoho offering and adding the functionality that is needed to round out a DMS solution.
The opendms team wants to explore all possible opportunities to take these apparent disparate (yet beautifully crafted systems) and bring them together as a cohesive set of offerings and craft them into the opendms open source portal and middleware platform.
This may seem a grandiose undertaking (given the “daunting” nature of building a DMS from scratch mentioned above) but the key to the opendms project is aggregation not construction; this is discussed in “development” and allows us to start small and build big.
As mentioned earlier, if one were to consider writing a big system modeled DMS it would be lunacy and the cost would be prohibitive; how do we know it would be? Simple really, the traditional DMS providers haven’t transitioned into the cloud space because they would have to replace every part of their big system with completely new software; it would cost tens of millions of dollars (if not hundreds).
The opendms team is currently compiling a list of cloudware products that provide functionality that a modern dealer needs in the 21st century information market-space and is documenting the various SDKs for each, mapping their data structures and conceptualizing how to integrate the various systems.
The goal is to write no software; of course that is not achievable BUT we want to get as close to it as possible.
As we said above, we want to use a telescope to find every bit of cloudware available and provide front-end and back-end wrappers under the opendms banner to produce a fully-feature cloudware replacement for the traditional DMS products.
We talk about this often on this site; it is in the very DNA of opendms that any branded solutions be open source.
Having said that, we would heartily encourage third-party providers to value-add the opendms product and would welcome dealers commissioning their own development and would be excited to see these “extra-curricula” developments offered for sale to the community in a opendms showroom.
The open source, freeware and shareware business model is not an opendms idea, it is a fully mature and successful business model for modern software design; just not in the DMS market-place.
In fact, if a traditional DMS provider wanted to be part of the opendms experience they’d be just as welcomed as any other. They could develop to the opendms “open source” specifications and consume the various opendms front and back-end layers and then take their product to market; the good news folks is that, for the first time, they’d be competing in an open market.
The opendms story will change over time. In fact, this web site should be considered the “proof of concept” stage and the opendms team (team) is hoping that, perhaps in 12 months, the page you are reading now will have been replaced with a “more mature” set of topics. This is early days for opendms and we’re positive it will morph and grow into something, whilst we have our predictions, we may not necessarily be able to predict today.
That said, the team will keep this site fresh and relevant throughout the life of the project and, we are convinced, that will be for a long time.
After all, how can the principle and philosophy of what the opendms project is encompasses; that is;
