Giving up control and making yourself dependent, in other words: being caught in a golden cage. Some charging station manufacturers are afraid of this. But the truth is quite different. There is no need to worry at all. If you decide to use EVerest, you don't lose any control. But you gain a lot of advantages!
At PIONIX, we talk to a lot of charging station manufacturers. Each of them wants to learn about the EVerest project. Alongside a lot of enthusiasm, we sometimes hear concerns like: "If we started using EVerest, we would lose control over our firmware. We can no longer work on standards like OCPP and OCPI."
Let’s demystify some preconceptions.
Control of the source code
As EVerest uses an Apache-2.0 license, you are free to use the source code as you like. You can:
- Use it in commercial products,
- You can modify the source code as you want.
- There are no requirements to give back to the community.
- You could even keep any patches or derived work internally. No issue at all!
As with any open source project, the biggest advantage of EVerest is the community and the work done by the community. To have a good working community it is very useful if as many companies as possible give back to the community. This can be as simple as creating issues when potential bugs are found, up to becoming an active TCS (Technical Steering Community) Member, and anything in between.
The TCS is responsible for the roadmap and architecture of EVerest, this is also a community effort.
Back to the issue of independence. If, at a certain point, you don’t like the direction the community is taking EVerest, you could fork EVerest. But a good piece of advice: Don’t do this lightly, forking any project means you won't be able to easily keep up to date with the work of the main project which results in a lot more effort to keep the fork relevant and up to date than staying on the main project. If you have good reasons: you could go, and won’t lose any access to your productive code base!
EVerest and working with standards working groups/committees
Using EVerest does not mean that you as a company can no longer work with the different standards committees and organizations. You can still be a member of the Open Charge Alliance (OCA). As a member of the OCA, your employees can still contribute to OCPP. As PIONIX we would love to see as many specialists from different companies as possible contributing to standards.
I have been active in different technical working groups over my career and I have seen how useful it is for any standard/protocol to have a good group of experienced engineers contributing with their knowledge and experience. In fact: many of the contributors to EVerest across the board are in some way involved in committees.
If you use EVerest, you can build a charging station without needing all the protocol knowledge, like OCPP and ISO 15118. You can trust and rely on the EVerest community. But I would always advise having a certain amount of this knowledge in-house, as these protocols are at the core of charging stations. In the end, it’s your business decision, how much knowledge you want to keep and build in-house, and how much time and effort to put into following/working with the committees.
In a nutshell: everything is possible, nothing is required!
Code First!
We believe EVerest can even change the way the committees work. Our CEO Marco has a dream: "Code first, document later".
Today, members of the committees write ideas into documents, review them, and then do “draft” implementations to verify if the ideas can work and if the documentation is clear and unambiguous. I agree with f Marco: let the committee members write code first. And base the documentation on a functional version of this code. Ideally, this is done the open source way, so anybody can use the code for their implementations or as a reference. Ideally, you can run this code directly in your production environment, as we aim to do with EVerest.
Within the EVerest community, we are starting to see the first efforts in this direction: Specialists working in standards working groups are starting to implement the protocol that they have been writing. What can emerge from this approach? Well, in short, EVerest could become the reference implementation for these protocols.
About the author Robert de Leeuw, Technical EVangelist at Pionix [LinkedIn]
Robert is an experienced software developer/architect. He is an EV charging veteran with 10+ years of experience. His focus has been on the protocols used in the industry. For years he has been leading the development of OCPP (de-facto standard for managing EV charging stations) and OCPI (de-facto standard for exchanging roaming information).
