There's a proverb that goes "If you want something done right, do it yourself". This could be Yoctopuce's motto, because we're truly committed to minimizing our products' and services' dependence on third parties as much as possible. And for good reason, as experience has shown us time and again, right up until this past summer, when we were unable to accept credit card payments in currencies other than the Swiss franc for over a month...
The fact is, we like to do things entirely on our own, from start to finish. Whether it's programming our web site or our back-office tools, manufacturing our modules, or developing programming libraries. Whenever it's practically possible to do it ourselves from start to finish, we prefer to do so. Some may find this inefficient, implied to mean financially inefficient, but for us, it's the most natural way to guarantee the quality of our services. Not because we think we do better than others, but because by doing things ourselves,
- we protect ourselves from unwanted changes that occur beyond our control;
- we maintain the necessary expertise within the company to provide high-quality support;
- we take direct responsibility for our products toward our customers and can correct issues immediately, as soon as we discover them or they are reported to us.
Local manufacturing
Although the assembly of our products could easily be outsourced to reduce costs, we are committed to keeping it here. Firstly, it is the only way to be truly certain of how they are manufactured. When inspecting a finished product, it is virtually impossible to know whether the reflow temperature curves have actually been adhered to, whether a component has been replaced with a cheaper counterfeit, or whether the capacitors are indeed the models of the specified quality. Consumer electronics are full of these cheap components officially specified as 'for consumer devices only', which do not last nearly as long as industrial-grade components.
Economically, there are also advantages to assembling our products ourselves: we can afford to manufacture products in small batches, the size of which varies according to demand. When stocks of a product fall too low, we restart production the very next day, thereby maintaining optimal delivery times for our customers. Our in-house stock monitoring tools are a far better alternative to mountains of finished products waiting to be sold.
But it's not just when it comes to hardware that we prefer to do things ourselves...
To Reuse Third-Party Libraries... or Not to Reuse
Not so long ago, rewriting code yourself that was readily available online was viewed by some as a sin. Code shared by others on GitHub, having been reviewed and improved by numerous users, was bound to be better than anything you could write yourself, even for the most basic tasks.
Taken to extremes, this principle led to a proliferation of ridiculously simple packages, and, more importantly, to the emergence of libraries with sprawling dependencies. The entirely predictable consequence was an exponential increase in the number of contributors to widely used libraries, and thus a dramatic increase in the surface area exposed to the risk of malicious code injection. To date, the official GitHub page listing packages in which malicious code has been detected contains more than 50,000 entries...
The massive outages and hacks caused by this phenomenon of uncontrolled code reuse have reinforced our commitment to always prioritizing "house-made" code. The rare exceptions we have tolerated are libraries that have no dependencies of their own, and for which we had a valid reason not to rewrite them ourselves:
- Mbed TLS: the quality risk involved in rewriting a cryptography library far outweighs the intrinsic risk of this library, which is compact, has no external dependencies, and is maintained by a professional team;
- ws: For several years now, we've chosen to use this de facto standard library for WebSocket support in Node.js; however, we may well decide to do without it in the near future, since we've already rewritten WebSocket support for several other languages.
Apart from these two exceptions, we use only the core libraries provided by the language itself in our programming libraries, and we make a point of coding the rest ourselves.
Similarly, in the firmware for our modules, we reuse only a few core libraries provided by the processor manufacturer as-is, but we reimplement all key components in our own way to maintain complete control over them.
The approach of coding everything ourselves as much as possible has two other advantages that have often been underestimated:
- it makes the developer's job exciting
- it keeps the developer's intellectual abilities at the level needed to provide quality support.
It took the advent of AI in recent years for people to begin realizing that delegating the development of key components to a third party, whether artificial or human, means choosing to lose knowledge in the relatively short term. And it's probably no coincidence that we now have to warn students that if they use AI instead of doing things themselves, they'll lose their enthusiasm for work.
But even though we like to do everything ourselves, we couldn't sell our products around the world without relying on a few IT services provided by third parties...
Use of External Services
To keep your Internet-connected modules synchronized, we partner with the NTP Pool Project, which offers NTP service worldwide. This is a service we could not have set up on our own with the same level of quality. But you're not required to use this NTP service; you can, of course, configure your hubs to use your own NTP server if needed.
To make our libraries easier to use, we publish them on GitHub and on various package distribution systems such as npm, PyPi, and NuGet. But you always have the option to download your libraries directly from our web site, without going through third-party sites.
Our web site, by the way, is hosted by a local internet service provider. They do a great job, provide us with ample bandwidth, and ensure that our server's operating system is constantly maintained at the necessary security level, better than we could do ourselves.
To accept credit card payments on our site, regulations require us to use an accredited third-party provider that is subject to rigorous security audits. And here, we have to admit that we weren't very well served this summer, and that we would clearly have preferred to be in control of the situation, just as we are with everything else...
The Credit Card Payment Saga
To make a long story short: in early July, following a change in the terms of our contract with our credit card processing provider, they made a change to our account configuration without informing us. This change resulted in credit card payments in currencies other than the CHF (Swiss franc) being systematically declined. All payments in euros and U.S. dollars consistently failed. No matter how many emails and phone calls we made to support for over a month, we were unable to get our provider to resolve the issue.
We ultimately had to switch to another credit card processing provider with better knowledge of his infrastructure. After a 40-day outage, and after implementing a new payment gateway with this provider in our online store, we were finally ready for the start of the school year.
We're sorry for everyone who encountered this issue this summer and we apologize for the inconvenience.
