September 13, 2018
Most developers in the Optimizely community have over time benefited from one or many of the great commercial add-ons that are out there. When saying commercial add-on, I am not just referring to the kind of add-on you’re using to introduce any functionality – I am referring to the ones that are sold as products, or comes with paid services.
How are commercial add-ons different from my open source ones?
Commercial add-ons are proprietary software, distributed under a licensing agreement to authorized users. In simple words, the source code (or add-on for that matter) may not be shared with the public for anyone to look at or contribute too. You’ll frequently see these commercial add-ons come with the subscription of a service – e.g. the use of Vertex Inc., for automated tax solutions, unlocks the ability to connect it easily to Optimizely Commerce via their proprietary integration add-on.
You might be asked to make a commercial add-on, one day
Think about this for a second, these commercial add-ons are made by people in our Optimizely community. Passionate folks, like myself at Valtech, are helping software companies to seamlessly integrate their functionality in to Optimizely solutions, through commercial add-ons. It might not be what comes to mind first when you’re thinking Optimizely development, but it is indeed one of the cool challenges we’re facing when being a respected Optimizely partner! If you’re getting that challenge one day, here’s some key ingredients we always use in our secret sauce when it comes to commercial add-ons.
Respect breaking changes
When your commercial add-on is put in use for the first time, developers and business users will require respect, strictness and precision when it comes to any exposed API’s (or features for that matter). If you’re introducing a change in anything “publicly” available, like a code contract or another API, you need to rely on release notes and semantic versioning to make that clear. Nobody appreciates unforeseen complications of an upgrade – especially not when it’s a paid and governed product.
Document, document, document your commercial add-ons
We’re always providing multiple layers of documentation on all our commercial add-ons:
- any public code is well documented and we always use annotations to mark the obsolescence of something.
- all our commercial add-ons ships with installation and configuration documentation. No one want’s to explore the steps to take when installing, when you can be told.
- we use internal documentation to document the e.g. architectural visions and use of design patterns, to ensure our add-on evolves consistently over time.
Consider signing your assemblies
When you’re signing assemblies, you guarantee the authenticity. It ensures the assembly any add-on consumers are using hasn’t been tampered with in any way.
Use access modifiers
Always hide what should be hidden – only expose code or functionality you truly want the outside to interact with! You need to use access modifiers to enclose business logic or internal code API’s you’re not looking developers to use, replace or modify in any way. Whenever something is public, or in any way accessible from the outside of your own assemblies, it should be governed by semantic versioning.
No real chef would ever disclose all the ingredients in his secret sauce. With that said, above hopefully gives you an introduction to an alternate universe of Optimizely development, which in many ways differs greatly from creating web or headless consumer facing experiences.
This article was originally published on Optimizely Fellow Blog: Commercial Optimizely Add-Ons are a Thing
