Over the course of Spree’s lifetime, there have been many extensions written. Some consist of features desired in Spree, and some consist of features removed from Spree. Many extensions were even written by Rails Dog before Spree Commerce was founded.
Over time, many of the extensions published to the Spree Spree Github Organization have been deprecated, become irrelevant, and been abandoned as community usage fell. This has lead to a lot of confusion about what is and isn’t officially supported by Spree Commerce. I’d like to take the time to clear up this confusion by announcing deprecated extensions, and what will be officially supported extensions going forward.
There are several reasons for these decisions, and we feel it will ultimately benefit the community. After all it was the Spree community who came up with the idea for the spree-contrib Github Organization at the last SpreeConf.
Providing a more centralized location to find Spree extensions, and a way for people to share their extensions is a big deal. We’ve seen lots of people trying to tackle the same problems, and releasing their own versions of extensions that never get found. This causes people to reinvent the wheel over and over again. We don’t want to see the extension ecosystem so fragmented that a dozen different people write their own Avatax or SOLR extensions. We believe making it easier for the community to collaborate on a single canonical project will make for better extensions with more support and less wasted time.
We want to broaden the committer base of many of these extensions, so that neglected extensions can be maintained by trusted developers outside of Spree Commerce. We don’t want to be standing in the way of the community upgrading extensions, and intend to make maintenance of extensions much easier and with a lower barrier to entry.
We think it’s important to manage community expectations by making it easier to tell what we support and what we don’t. There are lots of good extensions that we simply don’t support, but people still find useful. Luckily many of them live on, and are regularly updated by the community. Some extensions are not so lucky to have the community support, and when someone comes along trying to use a broken extension, it can understandably make them upset. We don’t always have the time to respond though, and we don’t want to leave people hanging on a response from us when we’re not even participating in the projects anymore.
Managing Time & The 80/20 Rule
We’ve had a long-standing 80/20 rule for Spree, and we believe it applies to the extensions we choose to officially support as well. When we receive new feature requests our rule of thumb is that if 80% of the people need this feature it’s probably worth inclusion. If something is a nice-to-have feature, but we only think 20% of people would use it then it’s probably not worth inclusion. Trying to please everyone, and simultaneously provide every feature is unsustainable. It also results in poor quality code.
Our goal is to provide the community with the best minimal, extensible, and flexible solutions that we can. In order to do that we’re focusing on what’s important to everyone, and will leave it up to the community to help us provide and support everything else.
Moving to spree-contrib:
Interested in contributing?
If you’re interested in contributing or helping to maintain any of these extensions please file an issue on the project, and we may grant you access depending on the extension. You may continue filing issues, and pull requests over on their new home in the spree-contrib organization as you normally would though.
Have an extension you’d like listed in spree-contrib?
If your extension serves a purpose not already covered by an extension or is a better alternative, we would be interested in providing it greater community support and visibility.
Some notable cases where we can already see this happening: