Solidus Conf 2018 Recap

A comprehensive recap of the incredible talks from Southeast Solidus Conf, and a passionate look at What's Next for Our Solidus Community.

---

The State That We Are In:

Solidus in a Post-Stembolt World

-Memphis, TN- Working remotely has its perks, but there’s nothing quite like gathering with your community in-person to learn from each other and work together. Being at Southeast Solidus Conf this August was an incredibly encouraging experience; and moreover, it was a reminder that there are so many of us who truly care about the Solidus community and are working hard to ensure its continued success.

However, this year's meeting was more important than usual:

It was impossible to miss the deja vu feeling of thinking back on Spree's storied past, and to when a few years ago, SpreeCommerece was acquired by First Data.

The overtones of similarity between Sean Schofield’s announcement that

“as a company [First Data] can no longer dedicate significant resources to [the open source Spree project]”

and Stembolt’s announcement of their acquisition by Juul were more than apparent.

Thankfully, Sean Taylor was much more-committed in his proclamation, giving us some hope for a much better outcome than with Spree:

“Through JUUL Labs, we will continue to develop and support the Solidus community that we’ve built together.”

But what does this community support really mean?

For better or worse, until now the bar has been set insanely high. Stembolt employed multiple core members, devoted countless hours to the platform from their extremely talented staff, and even paid for an incredible developer to work full time on the open source project. Simply put, it's not fair nor reasonable for us to expect this as the default from JUUL, who is now another one of many large stores on the platform, working primarily for their own store's success. Clarke and Sean’s #1 priority used to be Stembolt, their clients, and, most importantly, Solidus; now, it's JUUL. (But to be clear, that also doesn't mean they don't care about Solidus. They still do and we can't wait to see what's next from them.)

What's interesting about this realization concerning priorities, is that the same is true of most stores in the community. It's no secret: the big players tend to operate large custom stores, and slowly bow out of the community over time. And this is depsite their best intentions to contribute back. So what gives us the right to expect that JUUL would act any differently, contributing more than the rest of the community?

More importantly, Clarke made it clear while speaking in-person in Memphis that the community has to step up before JUUL pulls the trigger on any significant investment or work. This might not sounds great, but really, it's good news. He's saying that if the community leads by example, he'll make sure JUUL is also on-board in a major way.

So where does that leave us now?

Hawthorn is gone from the core team. So is Martin Meyerhoff. And so is Jordan. And effectively, so is Stembolt (who's entire website now redirects to that same blog post announcing the JUUL acquisition), and along with it, Stembolt's co-founders Clarke, and Sean.

I'd like to pause here and make a special point here of again thanking and acknowledging Jordan, Martin, and John. They made so many incredible improvements to the codebase and they'll be dearly missed on the core team.

In fact, Jordan and Martin each added almost 400 commits to the codebase! Apart from John, they are the top contributors in the project (except for those who originally built Spree, such as Ryan Bigg, Sean Schofield, Brian Quinn, and Jeff Dutil, Trung Lê, Roman Smirnov, and Washington L Braga Jr, who's lasting contribution is still helping us today). From all of us, a huge thank you for all your hard work, to both Jordan and Martin.

Incredibly, John Hawthorn now has 2,152 commits in the Solidus repo. Just let that sink in a little bit. Before his departure, he even recently pushed out Schofield for the #2 Contributions spot. Thank you SO much for all your hard work John.

Stembolt is dead; Long live Steamboat.

---

A Call For Leadership

Our community needs leadership and it needs it now.

We used to have 7 core members; now that team is down to 4.

This was a surprise to many of us in the community - so much so that Clarke actually apologized for the intense radio silence over the last 2 months (while they were working to close the JUUL's acquisition).

Before the conference, Taylor Scott was spot on in noticing the lack of information and activity in the community:

"Hey guys, I'm not sure if we're the only ones in the community getting worried. But it would be nice to get an update from the Core team on the state of Solidus? Since John Hawthorne has left it doesn't look like much work has continued on the project and in the last month 0 work. We would appreciate it greatly as seeing this does worry some of our higher ups." -@skukx

Unfortunately, the graph from today hardly looks any better:

The conditions now are critical and whether or not you're ready, we are now approaching a pinnacle. It's difficult to say exactly what to do but the change begins with me and I reflect it back to you (and you and you and you).

It's imperative that the community comes together to decide what's next. Luckily, Southeast Solidus was the perfect time and place to begin this process. And another huge thank you to Sean Denny who organized the conference and made all of this possible.

We can circle back around to this discussion about organizing our community and its leadership later on; first, let's run through a recap of the conference.

---

Southeast Solidus Conf 2018 Recap

Table Of Contents

0. Solidus Roadmap

Clarke Brunsdon from JUUL Labs

1. Creating a super-fast frontend with the power of StimulusJS

Eric Saupe from Deseret Book

2. Chatbots for Your Online Store

Daniel Pritchett from Gremlin

3. GraphQL and Solidus. An Empathic API Update 2 Years Later

Braden Douglass from Glossier

4. Experiences developing a POS for B2B

Edwin Cruz from Magma Labs

5. Harnessing Your Ecommerce Platform for Growth

John James from Engine

6. Solidus + SEO in 2018

Thomas Sample from Karma Creative

7. Taming the Business Domain

Jason Charnes from Podia

8. Headless e-commerce with Solidus, GraphQL and React

Alejandro AR & Daniel Honig from Boomer Digital

9. CXOps at Glossier

Peter Berkenbosch from Glossier

10. Solidus and the Enterprise: Making friends with ERPs, POSs and warehouse systems that don’t think you should exist.

Matthew Redd from Deseret Book

11. Solidus 2020

Blake Puryear and Jim Kane from Engine

12. What's Next

---

Solidus Roadmap

Clarke Brunsdon from JUUL Labs

The first speaker was, thankfully, Clarke Brunsdon, former CEO of Stembolt, now Senior Director at JUUL Labs. Clarke was finally able to address a lot of previously unanswered questions and relieve some of the pressure that had been building. He also proposed ideas on how to move forward from this very significant juncture. One this is clear: He wants to see Solidus grow and thrive moving forward. Yet, in his own words, big changes must to be made to ensure the platform's long-term success.

Clarke began his talk with the section that was most difficult aka addressing the elephant in the room:

"Stembolt's now been sold. For about 6 months now we've been in talks with JUUL Labs Inc to purchase to Stembolt. Sean and I thought long and hard about it. We did have to shut down Stembolt in order to do it. ... Yea so we got purchased and for the last 2 months there's been almost no communication from Stembolt, from Solidus, from anyone, where the project's going, what it's doing. ... It's incredibly important to us as JUUL to keep this platform maintained, and we know how difficult it's been for so many companies ... because we've just been incredibly quiet about that. Over the last, 2 months we've lost two of our maintainers that were there since day one. Both Jordan and John Hawthorne have now moved on to other companies, doing other things. Last December, we shut down Stembolt Europe, and with that we also lost Martin Meyerhoff from the core team."

"Again, we understand there's been almost no communication on this. ... [W]e didn't have the flexibility to reach out to the community to ask for help, to ask people to step up, to be able to communicate was was happening, and we just could not be more sorry. It was one of the most unfortunate bits of this deal ... Not being able to talk to everyone about what all this meant was just devastating for us. And so I apologize as Canadianly as I can, with a 'Sorry, eh'"

Clarke's talk isn't on Youtube yet because there were some technical difficulties during his presentation and he requested to rerecord the talk before it was posted. There has even been talk of a possible remote Q&A session in September.

If it wasn't clear already, two things are now both apparent and pressing: first, some of the core members have left and must be replaced, and second, Stembolt is gone along with out full time maintainer. These facts are perhaps the most relevant revelations to the future of Solidus coming out of Clarke's talk.

Most importantly, with John Hawthorn now working at Github, there is no longer a full time employee dedicated to maintaining Solidus.

Jordan Brough has also left, and is now working at Teachers Pay Teachers.

And yes, Martin Meyerhoff is off the open source team too.

The immediate next question should obviously be how does this change Clarke, Greggor, and rest of the ex-Stembolt team's involvement moving forward? They used to be a digital agency focused on Solidus. Now they are an ecommerce store like most of the community. Clarke again summed up the situation in clear honest terms:

"Now switching to JUUL, I work on a Solidus Store far more than I ever do Stembolt a consultancy. While I was with Stembolt, I could always count on the company there to support the platform. I always knew I was going to have maintainers on it. I always knew what that platform and direction looked like. And as JUUL, I have a lot of the same questions and comments that everyone does, which is:"

"How do we all keep working together?" "Who's gonna be stewarding this platform?" "How are we going to be maintaining it together?"

"And while many other people are sad that Stembolt is no longer there to do all the maintenance ... I am also incredibly sad and missing the fact that we're not there to look after this thing and steward it."

"We are going to have to change as a project because of that."

From here, Clarke moved on to trying to answer some of the questions and propose the changes he thinks we need. While some of his ideas may not be in alignment with everyone’s goals, it’s definitely a great start. One thing Clarke made clear: Stembolt is dead, and so now more than ever he does not speak for the entire community when he expresses what he thinks should happen next - but what's also clear is that he wants to continue to help Solidus succeed.

We all recognize that there are things wrong with Solidus, and that in the past it has been difficult for anyone, even large companies with their almost endless resources to contribute back to the Solidus core. Everyone gets focused on their own store and their own work and contributing back gets regularly deprioritized. Moreover, community members are wary that their work is too specific to their customized Solidus instance and won't be easily leveraged by other stores. Clarke talked about wanting to change that and to make it more accessible for everyone. He went on to highlight several major issues and to propose areas of focus (as partial solutions):

First, Clarke feels we must face the truth that Rails doesn’t scale, and so he feels we should consider pulling it out of core. He would keep ActiveRecord, but remove all webcode from core, and have us focus on stopping the use of "Rail-isms". Obviously, this is a major decision and makes us question what Solidus truly is. Case in point, tight now, our official tagline from the repo, is: "Solidus, Rails eCommerce System". -- This is perhaps the most controversial change Clarke suggests. We need to discuss this as a community.

Second, frustrated with his myriad of negative experiences, Clarke flatly told us that he "won't use Solidus Extensions" in his projects. He slammed our current system for carelessly modifying the Spree::namespace, making too many assumptions, and providing functionality by directly including themselves in our code (where we might not want them). However, the bigger problem is that he feels they make it almost impossible to contribute. -- When pressed on the issue in Q&A, he did admit that there was still merit in having an extension system in general, but that we had to completely rethink how they are implemented. This quote sums up his thoughts on the matter quite well:

"By modifying the Spree Core models, you are making a bunch of assumptions about how people are using your extensions. You are saying that when your code is running, you really want my code running instead. And that's not a sustainable, reasonable way for us all to share code. It so quickly breaks down: how you think an extension should behave, and how I think an extension should behave, are almost opposite in specific cases. If I were to make one request to extension writers, to people trying to share their code around, it would be: provide me the methods to do what I want to do, and tell me how I should be calling them, but then leave it up to me."

"So it's not like I think extensions themselves need to die, but how we use them and how we share that code has to significantly change. If I had my one way of how an extension should look, it would provide a gem, and maybe a 10 lines copy paste on 'hey this is probably where you should be calling it', 'this is how you should be calling it, this is how it should look like in your views, but they shouldn't try to inject their own thoughts into my application just because I include them."

Third, Clarke lamented how it's almost impossible to contribute back to core because it intertwines persistence and business logic, acceptsnestedattributes, and is resistant to change. Moreover, a high skill level is required by any developer trying to significantly contribute back to the platform. Spree::Order is a bloated 1200 lines and is largely unimproved since the Spree fork. In partial response to this, Clarke wants to complete and merge a few important existing PRs into Solidus core. These are: Event Bus, Remove state_machine, remove paperclip, and remove state machine. More will have to be done, but this should at least help us get the ball rolling.

Finally, since most Solidus stores end up replacing solidusfrontend, and since those who use it normally use the suggested implementation (of copying the view files into their root application), he suggested deprecating solidusfrontend and removing it from core. To this final point, Jared Norman, a senior solidus developer and ex-Stembolter who has recently started his own web development agency Super Good Software, later made an excellent suggestion: solidus_frontend could easily be replaced with a generator to create the views for those that need them.

Moreover, beyond these specific suggestions, we have to evolve faster so that Solidus continues to be relevant. The goals the platform had when it forked from Spree have largely been accomplished and we are entering a new era. Clarke laid out 5 new goals for the project, which he aims to move towards through the above suggested changes:

• 1. Abandon the mistakes of 10 years ago
• 2. Adopt the "right technologies"
• 3. Become easier to adopt
• 4. Become easier to work with
• 5. Become easier to contribute to

Seemingly everyone agreed that with these core members gone, the most important thing was to get new people on that team. There was some talk about who the new members might be, but nothing has been decided yet. Still, the changes we need go beyond just replacing a few core members. If we want to keep the current core members involved we need to change their role moving forward. The idea is simple: core would decide the technical direction and then hand that roadmap over to the new maintainers from the new Solidus Company itself; the maintainers would then execute on that direction. Clearly, this is a big change, but I think it is also our reality. If we want Clarke and Greggor involved, we must recognize the change in their commitments and the real-world time constraints on their schedules.

"One of the concerns I have as Clarke, open source person, is that this project doesn't get the time and attention it needs from Clarke, really busy person, and it suffers from that. And I think removing those roadblocks of specific human beings that could impact the project negatively are really important."

Beyond changing core's role, the bigger question still looms large. Who will steward the platform moving forward? Although many people seem to be interested and are willing to donate development time, what we really need is someone who can dedicate all (or at least most) of their work time to maintaining and directing Solidus. Accordingly, what Solidus needs most are people who are not just willing to commit to donating time, but people and companies that are able to give money.

I think everyone felt a weight lifted after Clarke spoke, despite the fact that it may have raised more questions than it answered. Clearly, there's work to do, but at least we now know where we’re at, and what we’re dealing with. Clarke made a point to say that this is on us now, it’s up to the community to make Solidus great, and he’s right. This community is strong, I have no doubt that we can take the reigns and do what is best for all of us.

It's time to take off our training wheels and decide if the open source project is something we care about, and if so, it's time for all of us to step up and make consistent and meaningful contributions.

I'll leave you with one final quote from Clarke during the Q&A after his talk, conveying the true gravity of the situation:

"There's no way, for the long-term safety and health of the project, I want this thing attached to me in any way shape or form. I use Solidus and I rely on it as JUUL but for us to continue to evolve as a project, it has to move past Stembolt. Stembolt is dead."

Go Back to the Table Of Contents

---

Creating a super-fast frontend with the power of StimulusJS

Eric Saupe from Deseret Book

The next speaker was Eric Saupe from Deseret Book, a company that has been building, expanding, and innovating for almost 100 years. Eric is a very senior Solidus developer with extensive experience throughout both the Spree and Solidus codebase, and the chops to work all along the stack wherever is needed. Before getting into his talk, Eric summarized Deseret Book's experiences with the platform we know and love, poignantly reminding us again NOT to use class_eval and giving us the secret to easy Solidus upgrades: remove your blocking customizations in core and don't add new ones.

"I will say that our journey with Solidus started with Spree and we were concerned about where it was going, and we found Solidus and we rewrote our site from scratch."

"We pulled in a lot of our old code from Spree...and that was a mistake and we have learned over the years that, like Clarke alluded to a lot in his talk, that the less times that you use class_eval the better your life tends to be."

"We have made it a particular goal for the team to keep up to date with all of the Solidus releases and I'm really happy to say that our store is running Solidus 2.6 and we continue to update as quickly as as we can. The reason that we're able to do that is because we removed all of our customizations that sort of block that kind of thing."

Though more of a backend expert, his talk focused on Javascript and using Stimulus: a framework which uses controllers, actions, and targets, to enhance the HTML that already exists in your code. The goal of Stimulus is to avoid doing more work when you don’t need to. It works in conjunction with other, more complex approaches, adapting to your needs, so instead of a whole lot of bloated javascript code from jQuery, you can use this streamlined approach to quickly iterate over common feature requirements.

"While other JavaScript frameworks may control your entire front-end, stimulus is built on the idea that you just need a little bit of JavaScript sometimes."

Stimulus was born out of a need for efficiency and standardization at Basecamp. They realized having too many different styles and patterns living in the same application made code reuse impossible. Moreover, this was causing on-boarding to be a slow (and grueling) process. Their solution was to write their own framework, combining the best of the paradigms and styles, and they called this Stimulus.

"Stimulus connects HTML to JavaScript through the use of data attributes. The way that they explain it is that the class attribute bridges HTML and CSS and the data-controller bridges HTML to JavaScript. So stimulus is continuously monitoring the page waiting for elements that have the data controller attribute, and when that attribute appears on an element, Stimulus connects the proper JavaScript to just that element (and scopes it to just that element), so this allows for reusable and organizable scripts throughout your application, that are only initialized when needed."

After introducing us to Stimulus, Eric walked us through several examples, beginning with something very easy and culminating with an attempt to create a single-page checkout in Solidus.

This was when the live coding began. (And honestly, it went awesome. He deserves a special honor for being brave enough to be the only speaker to live code while standing in front of us on the stage.)

Eric Saupe live coding during a demo of Stimulus.js

His first example was a simple Greeting using a user-inputed name, basically just an input and a button. Almost all that needs to be done is modifying the HTML to add a data-controller ("hello"), a data-target ("hello.name") for the input, and a data-action ("click->hello#greet") for the button, to run the greeting method when the target is clicked. The only thing left from there is to complete the corresponding javascript by filling in our controller: we simply add the target from our HTML ("name") and implement the #greet method that the data-action specified. And easy as 1, 2, 3, we have a beautiful little working alert greeting. However, as simple as this is, what makes Stimulus truly shine is when you realize how easy it is to refactor and reuse your controllers.

Next, Eric walked us through installing both Stimulus and webpacker in a Solidus app, and a few of the common configuration choices for Solidus along the way. Namely, switching out SQLite for Postgres, removing CoffeeScript, and finally (often) removing TurboLinks. In fact, most Rails developers seem to hate TurboLinks. While the potential increase in page speed is tempting, often they are too worried about side-effect bugs when javascript triggers misfire (or don't fire again). The most common case being a jQuery function wrapped in a document.ready check. Since TurboLinks doesn't reload the entire page (in order to boost page speed), the document is already ready and the trigger doesn't fire. However, since we're using Stimulus, we don't get trapped in this common pitfall. Instead, we have clear, consistent, and well-structured code. Accordingly, we decide to keep TurboLinks and capitalize on the speed improvement.

"TurboLinks works flawlessly with TurboLinks."

From here, the next tasks are almost trivial thanks to our community's well-crafted dependency management tools:

• To install webpacker, you simply add it to your Gemfile and run: rails webpacker:install.
• Then, to install Stimulus, you run yarn add stimulus, followed by adding stimulus to packs/application.js and adding both the javascriptpacktag and the stylesheetpacktag to the Rails application layout.

With the application set up and ready to go, including TurboLinks, Eric showed us one more example of a simple implementation for using just 'a little bit of javascript' before moving on to examples within Solidus. It was a great example of using Stimulus to create a reusable Clipboard function.

Next up was the challenge of implementing a carousel in Solidus during another Live Coding demo. Eric again showed how simple this was with Stimulus. By adding a data-controller, a few data-actions (for previous and next), and a set of data-targets (one for each slide) to his carousel layout (HTML), a few lines of code to his css (to show only the active slide), and filling in the Stimulus controller, Eric brought the carousel together in a snap. Though he had prewritten his controller code, it was still amazing to see such an often requested feature come together so quickly and seamlessly - but he didn't stop there:

Eric wanted to also illustrate the problem that Stimulus doesn't store state, and the solution that you can instead store it in your HTML. He walked us through the example of showing the second slide first, and went on to quickly further refactor his code.

Finally, Eric showed us the most challenging example he faced in trying to create a faster, single-page checkout in solidus_frontend. Unfortunately, he ran into problems at every turn, pushing his ingenuity to the limit, as he circumvented each one. In his own words, the end result wasn't clean and wasn't right, but he showed us his journey and the difficulties he faced such that a future developer might benefit from his experience. A summary of his changes were as follows:

• Redirect state URLs to just /checkout
• Render all checkout step forms at once
• Add javascriptpacktag to head on edit
• Disable jQuery handling remote: true
• Override edit to use API
• Add token partial for API
• Add HTML to big JSON
• Fix param_prefix on gateway to work with API

It was a learning experience, but it wasn't a loss. Wisely, Eric and his team instead chose a smaller but more effective goal: switch out jQuery and replace it with Stimulus, making TurboLinks once again compatible.

The implementation was straight-forward and the task was well-defined. Eric ported the Solidus javascript into Stimulus, rewriting (almost verbatim) the address state selector, the shipping address toggle, and the payment method selection (using Cleeve to replace the now deprecated jquery.payment for formatting the payment fields). The result was a faster, well-written extensible checkout process, seamlessly leveraging TurboLinks with no problems.

Eric made an extremely convincing case for using Stimulus, and how much it can add to your site. It's worth your time, go Watch Eric’s Talk on YouTube now.

Go Back to the Table Of Contents

---

Chatbots for Your Online Store

Daniel Pritchett from Gremlin

After Eric came Daniel Pritchett from Gremlin, who spoke about chatbots for your online store. The use of chatbots is becoming more and more popular, especially in ecommerce stores, and they can add an enormous amount of value. If you're interested in playing with some related artificial intelligence, Daniel recommends downloading some the Python Natural Language Toolkit:

"You can pretty quickly get into breaking up big huge blocks of prose into tokens into words and doing statistical analysis figuring out what this word implies about that word. It's a really fun place to start."

In fact, Daniel is writing his own book on Chatbots, and the core of the talk was focused on Chat-based Commerce.

From a high level, the three technology choices available for making chatbots today are: Hubot, Lita, and Pandora (which uses AIML).

Hubot is a JavaScript chatbot framework at least 5 years old, originally designed by Github to automate the company chat room. Today, Hubot has the built in ability to post images, translate languages, and integrate with Google Maps. But the real appeal of Hubot is that you can add your own scripts to make your own robot, and manage your deployment process through ChatOps. Hubot is open source, and there are a multitude of scripts available that people have previously written, but the ultimate goal is to create a unique Hubot for your company, and it seems like they have made this not only possible, but easy to do.

Lita is another choice that's not as big as Hubot, but on the other hand it's built in Ruby and it's open-source. What's particularly exciting is that it's designed to be very modular:

"Every time you build a new skill or technique you take it and you run a Lita new command and it generates a huge new tree with a ruby gem that plugs into Lita."

Comparing the two, Hubot does have some magic to it that Lita doesn't. You can write a few lines of CoffeeScript and you'll immediately have some existing code from the community ecosystem working for you, providing new functionality to your chatbot. On the other hand, though it might be a bit more difficult to get started, Lita focuses on both modularity and unit testing, making it a better long term choice.

The third option is Pandora, which utilizes AIML (Artificial Intelligence Markup Language) - a markup language allowing you to easily define input patterns and their corresponding response templates. PandoraBots makes it very easy to get started and start using their SaaS-like system for designing your own bot. If you want to see an extraordinary example of a chatbot built by Pandorabots checkout Mitsuku.

Daniel Pritchett shows off how easy it is to use PandoraBots to make your own chatbot

So what types of purposes might we want to use Chatbots for?

• ChatOps
• Concierge (for example, Intercom which you can use to bridge client-side js chat widgets to team members monitoring a Slack chat room)
• Helpdesk including automated phone systems with decision trees
• Conversation
• Commands / tasks (aka given a single input perform a task or command)
• Responding to inputs given in Alexa / voice assistants enabled applications

And while we're on the subject of Digital Voice Assistants, Daniel mentioned one extremely interesting past implementation: sending parsed data from user inputs to the Alexa API so that better responses could be provided to the user, potentially giving them the ability to leverage the full power of Alexa within their chatbot.

Turning to even more applications of these same ideas, he also mentioned using Instant Messenger Platforms and HTML-based clicky UIs (aka choose-your-own-adventure type response trees). One such example that lets you easily built fairly advanced functionality in Facebook is ChatFuel.

Another idea Daniel reminded us of is using chatbots to offer personalized recommendations for our stores. Better yet, he even provided a great way we can practically implement this ourselves. He describes it in detail in his 2014 article on Graph Kit for Ruby.

Finally, Daniel turned his attention to Virtual Brands. The concept is essentially making up your own brands by adding labels and other branding to generic drop-shipped products, often times only existing for a few months and selling to extremely specific niche markets. Chat-based commerce can be combined with Virtual brands through techniques such as Commenter Bots, Brand-building chats, and finally Intercom to pass along users back to humans waiting in a slack chat.

It was an extremely interesting talk and you should definitely Watch Daniel’s Talk on YouTube and start playing around with your own chatbots today.

Go Back to the Table Of Contents

---

GraphQL and Solidus. An Empathic API Update 2 Years Later

Braden Douglass from Glossier

Braden Dougless from Glossier came next. Glossier is a beauty company that challenges the traditional method used to sell beauty products. Historically, the so-called experts have told us, the consumer, what we should or shouldn’t be using on our bodies. Emily Weiss, the CEO of Glossier realized that what we, the consumer, thinks, is much more important and powerful. The brand is built on the idea that if they listen to what we think, and what we’ve learned from using all these products throughout our lives, they will have superior products, and a higher percentage of return customers.

At SolidusConf 2016, Braden gave a talk titled Empathy? Meet Happiness and API , in which he made the case for Empathy in development and especially in API design, espousing such practices as MINASWAN and SINASWAM (Solidus Is Nice So We Are Nice), and telling developers unfamiliar with the Solidus API to read the rSpec tests and then to come back to a more senior team member with questions. But importantly, at the end of the talk, he had "One more thing" and presented an important idea condensed into a concise phrase: "REST - Maybe It's Not Empathetic". What he meant by this was that perhaps to be truly empathetic (in the Solidus API), we must take a strong step away from Restful APIs altogether and towards the adoption of technologies such as GraphQL. Braden's talk this year explored this idea and told the story of his continued quest of a truly empathetic API.

An aside with a few small notes about sympathy, empathy, and spelling:

1. Sympathy is feeling compassion, sorrow, or pity for the hardships that another person encounters, while empathy is putting yourself in the shoes of another.
2. Empathetic is an adjective that describes someone or something that exhibits a high degree of understanding of other people’s emotions (aka empathy).
3. Empathetic and empathic are both accepted spellings of the word and can be used interchangeably. However, concerning the adjective for sympathy, sympathetic is the only accepted spelling.

Sources: Empathy vs. Sympathy & Empathetic vs. Sympathetic vs. Empathic

Walking us through his journey, Braden started by telling us about his effort to create an elegantly designed restful API for Solidus, again emphasizing some of the same tools he mentioned in his last talk, such as Swagger and Dredd to help test and document your API.

"Swagger, or (as it's been rebranded in the last couple of years) OpenAPI Spec, is a language agnostic way of representing a REST interface. This is commonly done with a list of endpoints with examples and runnable code that assists developers in exploring the entirety of the API."

"Dredd is another language agnostic tool that's actually deceptively clever. It validates that your documentation match that of your actual API backend. It does this by parsing those API blueprint markdown files (or one big Swagger yml file), and then builds the metadata into examples, that is then tested against actual REST endpoints."

Unfortunately, despite the flawless documentation generated by the request specs and fantastic validation, the results were not truly an empathetic API:

"At the end of the day, if the tools are too complicated, no one can, or even, will, use them."

Braden Douglass explains GraphQL Types

Braden continued by introducing us to GraphQL and walking us through a few basic concepts such as Types (for defining your schema and the types of objects returned by your API), Resolvers (for those unfamiliar think: GET requests) and Mutations (for those unfamiliar think: POST / UPDATE requests). Moreover, he also went on to argue that the private playground of GraphiQL is more empathetic than a well-spec'ed API because it allows increased autonomy when testing the boundaries of an API.

Finally, this brings us to today, where Glossier uses the core Solidus API (with some overrides) instead of their custom-built API on Glossier.com - while sprinkling in GraphQL where it's needed.

"These two pieces of technology should not be mutually exclusive. Not all API responses need sparse field-sets, or precise Swagger documentation, or an interactive explorer to understand the output. Sometimes you stumble onto a response that's so wildly underperforming that it only makes sense to rewrite it in GraphQL, or another technology. Doing this once shouldn't opt you in to a complete rewrite process."

He closed by making the final point that a Restful API may make more sense for services (aka computers), not for humans, whereas GraphQL likely is better suited for developers and more dynamic interactions. This was a very interesting talk. Now go Watch Braden’s Talk on YouTube. You'll be glad you did.

Go Back to the Table Of Contents

---

Experiences developing a POS for B2B

Edwin Cruz from Magma Labs

After Braden, Edwin Cruz from Magma Labs spoke about creating a B2B portal. He walked us through his process while identifying the challenges and the solutions he found. Working with large companies in Solidus can be difficult when they require multiple instances of different variables. The main challenge was developing an application capable of supporting a manufacturer who services multiple resellers, each with their own separate physical 'branch' locations. Some other requirements were supporting multiple users for a single company (reseller) and company specific Credit Limit, Store Credit, Pricing, Payment Terms, and (of course) Delivery Addresses.

Edwin had to figure out a way to allow for different prices on a single product, and to change those prices depending on not only which company is purchasing the product, but also which user from that company. He achieved this rather simply (thanks to some of the more recent changes to core) by adding a new column to spreeprices to specify the pricinglevel and providing corresponding functionality to set, manage, and display its value; primarily this this involved adding a new pricing_level 'enabled' Spree::Variant::CustomPriceSelector and Spree::Variant::CustomPricingOptions.

There were various other pricing related challenges, such as bulk updating product pricing. This was (again) accomplished rather easily through using a custom-built SpreadSheet import tool, once they jumped through the prerequisite Google API Authentication hoops. (Maybe we can convince Edwin to open-source it?) The main 'gotcha' here was accounting for updating product prices of items already in the cart. After careful consideration, Edwin's approach was to go ahead and update these prices, accepting the risk of having to issue discounts for any customer that might complain about their line-item price changing within their cart.

Edwin Cruz presenting how to develop a B2B Admin Interface

The next thing he had to tackle was the B2B Admin Interface. The application needed a way for a manager to login and setup the delivery address (for their branch locations), manage users authorized to make purchases, view order history, and configure general company-wide settings. Once the major challenges here were complete, they moved onto 'The real B2B Portal' where they optimized the experience for mobile, minimized typed input, provided payment-free checkout, and added easy delivery address selection, among other features.

One unexpectedly tricky change was implementing Selling By Weight instead of Quantity. Edwin was forced down a path of editing first order#populate, then the LineItems model, then the order contents, and finally the completed order inventory validator. Though they got it working, this later caused an expected performance issue stemming from the creation of an InventoryUnit record for each quantity at line item level (regardless of in-stock status and whether track_inventory was turned off). This is still something they are working to improve.

Another cool idea was how Edwin developed a way to create 'order evidences': proof that the orders were delivered and paid for, and sent as updates to the company owners.

"So it was pretty easy, I just added a new tab to the orders to manage all the attachments ... the company owners could just go to the order history and they will see a new option to see all the evidences, all the attachments. ... And it was pretty easy. I was surprised that with these few lines of code, I was able to add attachments to the order."

Another very cool trick he included (that we all might have a need for) is sending these attachments as inline images:

Rounding out the project, he cleverly reused his existing store credit feature by having an admin user assign store credit to fulfill pre-paid orders. Similarly, in another example of working smart not hard, he reused the SpreadSheet import tool to provide both Cost and Inventory Management to administrators.

Edwin's final challenge was when the business requirements changed so that the pricing_level could be set on a per-product-taxon basis, rather than only a per company basis. Despite the unexpected obstacle, it seems like he jumped over this final hurtle with relative ease. Edwin is a fantastic developer and truly understands how dedication and perseverance can conquer any problem. This situation was no different.

As a bonus, Edwin also shared his suggestion for us to use the roadie-rails gem to help easily process SASS into inlined css for your emails and the browser gem for mobile detection. Yet another bonus was when he showed us his work on streamlining our dependencies by only including the parts of the AWS SDK that we are actually using:

"I got tired of seeing the AWS's SDKs loaded every time, so I tried to see how I could just include only the S3 gem, and it was kind of easy. I realized that AWS SDK was only needed to define the AWS version, so the only thing that I did was to add this file which is in lib, awk-sdk.rb with these two lines of code: require aws-sdk-s3 and Aws::VERSION = Aws::CORE_GEM_VERSION and that was it. That was the only thing I had to do to remove the whole AWS SDK gem suite - you know because it has a lot of gems, but I only needed to include the one for S3."

Edwin's talk provided practical concrete examples of implementing B2B functionality in a Solidus store and I'd strongly recommend it to anyone looking to take on a similar project. Go Watch Edwin’s Talk on YouTube now.

Go Back to the Table Of Contents

---

Harnessing Your Ecommerce Platform for Growth

John James from Engine

The last talk of the first day was by John James from Engine, one of the main sponsors of Southeast Solidus. John spoke about how to harness your ecommerce platform for growth, and told the impressive story of how he built multiple insanely successful companies before starting Engine, so they could help others do the same. He showed us why quality is often better than quantity, and how he used content to build revenue. Through experience, he learned that small data was better than big data when it came to customers and that you don't need some complicated big data project to find trends and sell more products.

John started out by telling us his story of how he got into the business, originally starting his first store from his dorm room back in medical school, 23 years ago. It was in 1995 at the University of Arkansas in Fayetteville, living with his co-founder Jim, who was his freshman roommate until they couldn't stand living together (all of about 1 week). He created a business based on some guestbook software he found and sold QuizBowl questions - and PAID for his medical school.

From there, John 'graduated' to Yahoo! Store when in 2001 his brother, the president of Sunbeam Outdoor (the then largest manufacturer of BBQ Grills in the world), called him for help. While working as a medical family practice resident, working 100-hour weeks, he built GrillStuff.com a online BBQ Grill store leveraging Google's ridiculously low cost CPC-Platform for the most common terms. They were buying keywords like BBQ Grill for around a penny on Google, or for a nickel on Overture (now Yahoo Search Marketing). It was wildly successful and he eventually left medicine to pursue this business.

Building on this success, in 2005, John called his old college roommate Jim and together they transitioned to using X-Cart, and then before long J-Cart (their very custom version of X-Cart), and, in a crescendo, finally sold that business at the end of 2008.

From there their choice and ambition was clear: if it doesn't exist, roll your own. Leveraging their experience, this time they choose a business based off of harvesting demand on Google. They called it Acumen Brands:

"At the time it was, what, 500 different domains that all went to one single backend and they had like EverythingPotStore EverythingTvStand and stuff like that, so now that's the basis of Wayfair. ... I started the exact same model in 2009. ... It was a Google-centric harvest demand model so user X searches for query y, we send them to page Z to fulfill that query and harvest the demand off of Google."

Unfortunately, this model was out priced relatively quickly as words like BBQ Grill were suddenly $3 instead of $0.01 -- Still, the effort towards a custom solution was fruitful as John persevered; he built an impressive 20+ store multi-tentant Rails-based ecommerce application, specializing in quickly building brand new stores (focused around selected market-researched keywords) in only a few weeks. By this point securing funding was easy and they took their first investment from a local source in Fayetteville.

Although this partnership between an ex-doctor and an ex-laywer in Arkansas was untraditional in ecommerce, together they built a successful ecommerce company selling medical scrubs and many other products, and raised multiple millions of dollars in their first round of venture capital investment. Wanting to stay ahead of the curve, Acumen took about half of that capital and bought automated robots to fulfill many of their products even before they had the demand to justify it.

Thankfully before running out of money, Dillard's Department Store from Little Rock stepped in and gave them the life support that they needed. This gave them the opportunity to launch Country Outfitter, leveraging Facebook's nascent platform and its recently released power editor feature, allow them to win big by uploading tons of ads in a single file.

The new market provided an exponential opportunity for growth as they jumped orders of magnitude from targeting keywords like 'cowboy boots' with 135,000 searches per month, to a targeting 18.2 million female Facebook users within their chosen demographic. However, they quickly realized that in the 2011/2012 market there was no way to close a transaction on the first click so instead they captured an email address from each visitor so they could get them to come back.

Incredibly, using this strategy, over the course of a single year, they grew the company from $60k-70k per month to whopping $14 million per month - raising 93 million in venture capital along the way.

John James showing how he grew his business exponentially

Generously, John walked us through the keys to this unheard of rapid success:

• As was already mentioned, John and his team leveraged Email Collection to build a base of potential customers who could then be retargeted using strategies such as email marketing.
• The idea is simple: a product giveaway. Offer customers a chance to win a free product in exchange for an interaction on social media, such as a like on Facebook. From there, advertise to the group that's already interacted with your brand: Offer a 20% discount in exchange for completing a 3 step easy sign-up process (where a user would provide their email, share the offer with their friends, and become a fan).
• Country Outfitters was ahead of the curve with Mobile First Design and support. He said this was a huge key to success as they were doing it before many others. It's even more important today than it was then.
• Instead of 'dumb' abandoned cart and monthly newsletter marketing flows, John used Event Driven Flows to drastically increase conversions - advising us to think about small data, instead of the often failure-prone big data. (For those unfamiliar with this, think: "User X does event Y, marketing cascade Z happens".)

"You don't need AI in order to say that user X, is a 35 year old woman from Georgia and looked at this boot to determine what [to do] ... it's an excel query"

However, none of this would've mattered much without the keystone: Content + Commerce So they did what you might expect and built an integrated blog CMS which allowed inserting products from the store into their blog articles and content, created shopable imagery (like Houz does today), and implemented swipe-able Lookbooks.

"So you've got 11 million subscribers, you can't yell cowboy boots at them everyday - Buy Buy Buy -> Unsubscribe. Goodbye."

"So what we did is built a publishing arm ... and so we'd speak the country lifestyle to these people - oh and by the way, we'd whisper 'we sell cowboy boots'"

The end result was fantastic: 18 million Monthly Page Views to this new content section of the site. The final pieces were A/B Testing (including many Landing Pages) and Cohort Tracking.

Unfortunately, the story takes quite a bad turn here. They sold the company to a Private Equity firm and 18 months later John left the company entirely, largely due to the fact that changes to the Facebook Algorithm had invalidated their previous business model.

One of the biggest takeaways from Johns talk though, was something that we probably all know, but it can never hurt to be reminded of: the big platforms like Facebook and Google are constantly changing. You have to be able to get customers off on to your own platform, instead of heavily relying on them. This helps to ensure that how we generate revenue will always work, even in the face of radical algorithm changes.

(Un)surprisingly, the bigger problem was the transition to Demandware after most of the talent left; despite it's enormous price of around $1 million per year, it was actually terrible and there was a 38% drop in conversion the day they switched.

A word to the wise: Half of this drop - a full 21% - was due to the change from their super-optimized, partially pre-filled, single-page checkout to a 4 step flow dictated by Demandware. John paused here to remind us of something we've all been putting our heads in the sand about:

"Solidus doesn't have a good checkout experience, by the way."

Other contributing factors included a loss of event driven marketing flows and an organic traffic drop because of the inherent loss of SEO-friendliness implied by the switch to Demandware.

When it was time to move on, John decided to open a Startup Studio, looking for investments and partnerships, and to give back to the community. He and his team met with 200 ecommerce founders, doing market research for their next company, and along the way partnered to launch 16 successful ecommerce companies.

Menguin was a highlight with a $25 million exit, but it was built on Drupal.

"You look at the struggles of Menguin, and that's one of the reasons why we decided to do what we're doing today at Engine: we couldn't find a piece of software to allow us to do all the growth marketing tactics and to be able to be flexible and change with the times."

They even tried Shopify, but had only limited success. On the one hand, clients loved the autonomy they had once the site was complete. On the other hand, the customer shopping experience was terrible and it was incredibly difficult to edit the code in such an essentially closed-source system, creating a ceiling when successful companies need advanced features requiring more complex integrations. Not being to edit the code makes these integrations essentially incompatible with Shopify. Just as bad, too many must-have plugins end up killing page speed (which is poor overall to begin with).

But they didn't want to roll their own again; not after spending so much time building and, worse, upkeeping a myriad of small features last time around.

"And so we found Solidus."

"I was at an ecommerce forum ... it was Lightspeed Venture Partners, it's a billion dollar West Coast firm. I think they've got a New York office as well. You had ex-Bonobos guys in there - Craig's running Care/of - you know, a few others, and so I went around the room and said, 'What platform do you use?'"

"About a third of them were using Solidus."

"And I was like, I've never heard of Solidus, and sure enough come back, and I don't even mention this to Jim, and Jim and Blake both come to the same conclusion from a developer side, like, Solidus...it's kind of got everything we need. It's missing a lot of things, but it's got a lot of the stuff that we need, and this is super exciting."

From there the decision was easy. They were going to build a solidus-based platform (think: Solidus-As-A-Service), and offer services such as Customization / Integration, Hosting, and Support.

But what's next?

Working partially through venture funding, John is already capitalizing on a new 'Ease of Use' layer with Kubernetes-based hosting, working on a more accessible admin, creating better documentation (especially for the decision-maker and end users), and extending Solidus's functionality with Marketing tools, such as event driven marketing flows that leverage a combination of Solidus + Klavio, aka content + commerce.

A big thank you to John for introducing himself and Engine to the Solidus community. We're thrilled you chose the platform to build your content + commerce service on top of and we can't wait to see what's next. I know this summary was very long, but that's because John's talk was awesome. Even this writing can't truly do it justice: Go Watch John’s talk on YouTube right now.

Go Back to the Table Of Contents

---

Solidus + SEO in 2018

Thomas Sample from Karma Creative

Starting day two was Thomas Sample from Karma Creative (that's me!). The talk was an info-packed speech on Solidus and SEO. - Quite clearly SEO is a topic that could fill multiple talks, but I think I did a very solid(us) job of touching on all the relevant information, perhaps with the exclusion of Social Media (but hey, I only had a 40 minute slot). In a future blog post, I plan to revisit the content of the talk and include this additional and essential information on Social Media.

There's a lot here to think about and unpack but I'll give you a few of the most important takeaways and provide you with an outline of the information provided in the slides.

A small note here: I purposefully made my slides rather dense so they'd be more useful during post-conference review. I highly suggest you take a look as you watch the talk, if you're interested in closely following the content.

I tried hard to not only explain the facts, but to give you a plan on how to implement what needs to be done. And let me again reiterate, this is a plan you need to start now, regardless of what phase your business is in:

"SEO is a marathon. Not Sprint. And you need to start running today. Not after months of initial development, after finally deploying your production app."

One way to think of this is that there's a missing team member, who could add a ton of value to your company, and who should be included from Day 1, as you quickly launch your blog and begin building your content, backlinks, and traffic: SEO, PR, and Copywriting.

Thomas Sample explaining how to use SEO to benefit your business

Without addressing Keyword Research, Technical SEO, Original Content, and Off-Site promotion, you're not doing everything you can to help your business or your client succeed. While some of these techniques seem to be marketing-oriented, there's no reason developers can't take a swing at them too.

The result is an application with SEO that's even baked into it's implementation (with aptly chosen model names, for example), beautiful URL and site structure, and blazing fast speed (among a myriad of other things).

The talk runs through a ton of ideas so as I said, for now I'll keep this to a simple outline of the information provided:

1. Planning:

   • Keyword Research

     • Demystifying Keyword Research
     • Qualities of a Good Keyword
     • What Keywords Have These Qualities?
     • Generating Lists of Potential Keywords
     • Filtering and Choosing Your Target Keywords

2. Technical SEO

   • Sitewide Optimizations

     • URL Structure
     • Use SSL
     • Mobile & Responsive Design
     • Crawl & Audit Your Site
     • Canonical URLs
     • Avoiding Duplicate Content

   • Metadata

     • Title Tag
     • Meta Description
     • Meta Keywords (hint: don't use them)

   • Structured Data

     • What Is It?
     • Choosing JSON-LD
     • Structured Data Testing Tool
     • Working With Solidus

   • Optimizing for Speed

     • General Info, Tooling, & Auditing
     • SEO-Friendly Assets
     • Reducing Redirects
     • Browser Caching
     • Server Performance
     • Using a CDN
     • Reduce DNS Lookups
     • Critical Load Path

3. Original Content

   • Content Marketing

     • What Is It & Why Should You Care
     • Short Attention & Doing It Right

   • SEO Content Guidelines

     • Headings
     • Media Rich Content & Keyword Frequency
     • Internal Linking
     • Social Share Buttons & CTAs
     • Avoiding Keyword Cannibalization
     • Avoiding Poor-Quality Content
     • Ultimate Guides

4. Off-Site Promotion

   • Link Acquisition

     • Outreach and Connection in the Digital Age
     • A Simple (yet time consuming) Process
     • Understanding What Makes a High Quality Link
     • Example Techniques

   • Ranking in Local Search

     • Google My Business
     • Local Links
     • Citations

5. Run Down

   • Measuring Success & Closing

     • Measuring Success
     • The Case for the Missing Team Member -OR- Proposal for a New Project Track

   • Tools & Sources

     • Tools
     • Sources

If you're interested in putting practical business value first, you need to seriously consider what you're doing for SEO. Start right now and Watch Thomas’s talk on YouTube.

Go Back to the Table Of Contents

---

Taming the Business Domain

Jason Charnes from Podia

After Thomas was Jason Charnes who talked about taming the business domain in a way that a lot of people might not think about. While it has become a fairly common practice in our society today to put some focus on mindfulness and meditation, not everyone would put programming together with these ideas. But Jason did, and it really got me thinking about how much that could add to everyone’s productivity and well being.

“To start taming the business domain, or the code we write, we need to focus on more than code.”

Jason told a story about two developers who each took a different approach when presented with a new feature to develop. One who tackled the problem head on, and was able to quickly put out code; but with no design, the code ended up being difficult to modify when new things were demanded of it. The other spent some time thinking about the code she was writing, and developed a solution with good design that, in the long run, made making changes easier, and saved time. This is an illustration of the Design Stamina Hypothesis that Martin Fowler introduced in his 2007 blog post.

While Fowler (and Jason) admit that this in in fact, just a hypothesis, and is impossible to prove, it is also an axiom.

"We may not have objective proof that this effect occurs but many of us feel that this explains what we see qualitatively in the field.”

Jason made a point that he was not saying having no design is wrong, just that it is beneficial to have good design. Despite his understanding of this principal, Jason told us he is often in the first group, just putting out code as fast as possible; I think we can all relate. Not that this is in itself bad practice, but being able to take a step back and really think about what we’re doing could be extremely beneficial in the end.

So how do we do this? How do we learn to think deeper about what we are doing, and about the problems we are trying to solve? Jason highlighted three ideas:

Jason Charnes presenting how to use mindfulness to tame your code

1. Mindfulness. Giving whatever you are working on your full attention, thinking deeper about potential solutions without letting other thoughts get in your way. This is hard and takes some getting used to. What's important to remember is that you don't need to push everything else out of your mind, which most people find almost impossible. You just need to let those other thoughts pass by without latching on to them, which is doable with some practice.

Mindfulness: "Awareness without judgment or criticism" --Jan Chazen-Boys

2. Focus. We all get distracted when we are working, whether it's by email, social media, or life outside of work. But learning how to not get pulled down these rabbit holes can result in you being exponentially more productive. Cal Newport says:

“Work is the ability to focus without distraction on a cognitively demanding task...we have to intentionally fight distraction in order to do deep work.”

I think the most important word to focus on here is intentionally. Do everything with intention and you will be able to focus on whatever you need to.

3. Simplicity.

"Simplicity is difficult. Software development: it takes a lot of deep thought and focus to tear apart complexity, to achieve simplicity."

Jason went on to make an important distinction: simple does not mean the same thing as easy. Rich Hickey talks about this concept in his 2012 Rails Conf Keynote speech which Jason highly recommended watching. Hickey defines easy as something familiar, something you already know, or something similar to what you already know; easy is also relative, or subjective. Simple, on the other hand, is when you have only one fold, one braid, or one role (as opposed to a braided rope, which would be an example antonym, aka complex); simple is objective. It's important we keep this distinction in mind as we tackle difficult problems with simplicity, focus, and mindfulness.

Taking a step back, and putting these three ideas together we can see that in order to be more productive, and to do things with intention, we need to pay attention and fully acknowledge what we are working on. We need to not let ourselves get distracted by those things that make us lose focus, and we need to embrace simplicity, even when it's not easy. For a more in-depth look at these ideas, Watch Jason’s talk on YouTube and start putting them into practice to benefit your own work.

Go Back to the Table Of Contents

---

Headless e-commerce with Solidus, GraphQL and React

Alejandro AR & Daniel Honig from Boomer Digital

After lunch, Boomer Digital presented about headless ecommerce with Solidus, GraphQL, and React. Daniel Honig begin by talking about doing more with less and moved on applying this concept to Solidus, and ecommerce as a whole.

Daniel Honig talking about how to do more with less

While Solidus has a lot of things going for it, in order to stay relevant, Daniel advocated for figuring out ways to keep it more in line with the changing world around us. To this end, his team has begun to research how Solidus could fit in to this more cloud-native future through the use of Headless eCommerce (implemented as a fully static website. With no defined front-end, customization is easier and the focus is back on user experience.

Daniel praises this approach as quicker to roll out new features, and having less of a need for full-stack developers. With no limits from a defined frontend, you can use the tool that works best for each thing you want to do, building your website, without the technical debt of features you don't want or need. Order Cloud has a great, comprehensive blog post about it Headless eCommerce which I highly recommend for more information.

One of the tools Daniel talked about, which has come up a lot in this conference, was GraphQL. He uses it as a conduit for their API in the headless application and feels this should be added to core to help us stay relevant:

“GraphQL is the single most important feature that needs to be added to core to keep Solidus relevant for the next generation of ecommerce websites”

Alejandro, who was dialed-in remotely via an unfortunately fairly spotty Wifi connection, then gave a fantastic screen share presentation showing us an example of headless ecommerce. Still starting with Solidus, Alejandro took us through a site he built that used Netlify as a hosting service and CMS interface, GraphQl as an API, and GatsbyJS as a static generator.

Netlify is a cloud based hosting service that provides a comprehensive and intuitive platform where you can integrate, make changes, commit, and deploy, all in one stop. It works as a CMS and creates an admin panel that anyone could learn how to use. Through this demonstration, it was easy to see why Netlify is a great tool to have as part of any headless ecommerce application.

It was fast, making changes was simple, and everything was straightforward. There are so many tools at our disposal, and when they are combined in a way such as this, they can do almost anything. While it's tempting to get used to using a robust ecommerce framework such as Solidus, there is so much more we have access to. As Daniel said:

“It’s up to all of us to make a difference and move this thing forward... If we don’t make this framework relevant, we may be predicting our own doom in the future. So we need to make changes, and let’s not be afraid.”

Now go Watch Daniel and Alejandro’s talk on YouTube to see for yourself.

Go Back to the Table Of Contents

---

CXOps at Glossier

Peter Berkenbosch from Glossier

Peter Berkenbosch then spoke about CXOps at Glossier and about the importance of working together within your company to ensure your customer is getting the best experience. At its heart, the strength of the company is in its technology.

"Glossier might be a beauty business, but's it's actually a technology company."

However, despite this focus, Glossier was experiencing a lot of pain in their technology department as they saw exponential growth across the company and a huge demand for new features.

To address this, Peter and his team embraced a new concept they call being Scrappy. As he goes on to say in the talk, this has helped them successfully navigate a myriad of complex challenges - allowing them to quickly respond to what was most urgent while staying productive as a team amidst quickly changing priorities.

"Just be Scrappy. ... It doesn't mean to make bad code, it means that we focus on getting code shipped. Fail Fast. Fail Often. ... Improve and Repeat."

Before this change, the solution for helping out the G-Team (Glossier's Customer Support Team) was a rotating Sheriff role where a single team member was on-call for a week long shift. This wasn't ideal already, but was made much worse by having a ton of different lines of communication such as email, slack, and in-person requests. It was a huge interruption to addressing larger issues (like feature work) that needed focused attention. This resulted in poor productivity, no way to scale, and no way to figure out the root cause of problems (drawing focus instead towards solutions such as simply hot-fixing a problem order).

The first step was to find the right tooling, but of course this led to the question of exactly what the tooling was for. After some careful consideration, they decided to view the G-Team as an Internal Client. This made it easy to see what was really needed: a ticketing system.

After evaluating their options, Help Scout was the clear winner. It gave them everything they were looking for in a ticketing system and also a lot more. One of the main benefits was an increased ability to spot trends in the issues being filed. With a single point of truth for all requests, patterns immediately became much more apparent. In a similar way, by using Help Scout's built-in Knowledge Base tool, the team was able to consolidate documentation for common issues, expediting on-boarding for busy seasons, and further improving team efficacy.

Another useful tool they found was Datadog. Which they used for a lot of things, but one of the most important was allowing them to store metrics on order volumes: when there's a downward trend, they can take notice and, where appropriate, take action. What kind of action? Well, a Scrappy one, of course!

Using a Scrappy process means many things, but a lot of it boils down to focusing on the effect of your work on customer experience and business value, as opposed to the abstract perfection that we all tend to seek in our code.

Peter Berkenbosch explains how to be Scrappy

The first line of defense is in evaluating whether or not to fix an underlying problem or to focus solely on the immediate concern. Scrappy says that for some temporary issues, especially those effecting only a small percentage of users, sometimes the best approach is simply addressing the immediate customer service concern. Building on this idea, something even more important came out of this practice:

The Autofixer.

Once they had switched over to Help Scout, Peter and his team quickly realized they had a very troubling edge case. Sometimes the state machine (that we love so much) had a completed order on the frontend but had missed critical backend callbacks such as sending an email confirmation, or, worse, leaving an order unfulfilled.

"So what we did here is to Go for the Scrappy again. The callbacks didn't work and we didn't want to spend weeks and weeks in rewriting the callbacks system, or get the state machine to debug what's actually going on."

"So instead of wasting those hours, we wrote a well-defined and well-tested service that queried for those problem orders, fixed the completedat date, for example, triggered all the aftercallback hooks ... so customers get their email, [receive] their products, and the order will be in the right state."

"It still had that problem in the code, but we wrote a vertical edge case solver next to it. And again, this way we buy time for the other tech teams to dive in and actually try to fix this specific problem."

"And the Autofixer term was born. And we have a bunch of them running right now."

Peter also gave two more examples illustrating the practice - one concerning a 'plane-crash' level error of double charging a customer for a purchase, and another aimed at drastically improving ease of returns and exchanges. In both cases, the Scrappy approach led them to creating an Autofixer-like solution, letting them quickly pick up adhoc requests while buying time for other developers to solve underlying problems.

The bottom line here is that it works. Using a Scrappy approach to CXOps, Peter and his team drastically improved the technical support process for the G-Team and streamlined their productivity. During the next busy season, sanity was restored amongst the team and everyone celebrated the enormous improvements they had made, which hadn't been truly apparent until they had been put to the test; the difference was clear and apparent. Go Watch Peter’s talk on YouTube now.

Go Back to the Table Of Contents

---

Solidus and the Enterprise: Making friends with ERPs, POSs and warehouse systems that don’t think you should exist.

Matthew Redd from Deseret Book

Following Peter was Matthew Redd from Deseret Book, who presented ideas that could provide enormous benefit to all types and aspects of business, not just software architecture. He talked about how Deseret Book has grown through the years, with some trial and error that has ultimately resulted in their great success. Since Deseret Book has been around since 1866, they have had experiences most of us haven't, and have so much knowledge to share that we can all learn from. It was fascinating to hear what they’ve been through, and how they’ve made it work so well.

All ecommerce sites have a way for their front end to talk to their other systems: accounting, shipping, supply chain, etc. While some small stores that are just starting out might be able to do this manually, at some point they will have to figure out a way to automate everything. For Deseret Book, when they first started using computers in their business, all the systems were separate, and they needed to figure out a way to get those systems to talk to each other. They began using an ERP, which stands for Entity Resource Planning, and was developed by the Gartner Group in 1990. This ERP combined everything in one system that worked together well, but was so severely integrated with itself, it would be very difficult if they needed to incorporate any outside systems in the future (such as spree or solidus).

As you can imagine, with a growing company trying to get its feet into the online commerce world, Deseret Book needed to find a way to integrate its new website with its ERP, as they replatformed onto Spree. Unfortunately, it turned out to be a very difficult thing to implement. Every system in the ERP was so intertwined with each other, that they couldn't simply add an outside entity and expect it to work correctly; they had to make some changes. Now this is where they ran into real trouble: resistance to change.

People don't like change. Matthew quoted Grace Hopper who was a pioneer of computer programming, and really understood how people worked in respect to change.

“Humans are allergic to change. They love to say, ‘We’ve always done it this way.’ I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.”

With a company such as Desert Book, who has been doing things successfully for so long, the people working in each department were, understandably, not keen on anyone trying to change anything. When the team implementing Spree came to them, asking for certain allowances (such as charging for purchases before shipment, something the company hadn't ever done before), they said no...and the team was forced to find a work around.

To solve this challenge, they created BlackBox, a middle-man between Spree and the ERP, so no information was directly shared. Though this took a lot of work to understand the Oracle ERP system, this at least initially worked. Tragically, before long they started to run into problems which led them to slowly chip away at the very abstraction that was their initial goal. Bit by bit, more and more pieces of the architecture spoke with each other, eventually resulting in a veritable web of connections.

Thankfully, out of the darkness came the light, as this nightmare led them to a new strategy.

Surprisingly, after much concentrated thought, what they came up with, was the old strategy; it would work this time - they just needed to figure out how to do it right.

What they realized was that the first time, they didn't dig deep enough into the business requirements and constraints. In a good natured what, they had instead just accepted the various departments telling them no. This time would be different. Most importantly, in order to get everyone working together on the same side, so they could get all of the systems working together, they realized that they had to figure out how to build trust.

The first step was to forge this deeper understanding between departments:

“Seek to truly understand the business processes that we’re writing software to interact with and to automate”

This understanding is important not only to be able to figure out the best way to change and improve, but also to ensure the people who have been doing it daily know that you are on their side, and trying to make their lives easier, not more difficult. This creates empathy and respect among colleges, which is vital to a successful company.

Matthew Redd shows the importance of asking "Why?"

Along the way, there were two questions Desert Book used (and continues to use) to achieve this.

One is to keep asking 'why?'', at least five times, so you can really get to the root of the problem. This technique was created by the pioneer of the Toyota Production System (you can read about it more here to truly understand any problem in order to come up with the best solution.

The other is 'what would have to be true?', and it's all about helping others suspend their judgement long enough to make your case, and hopefully build trust and cooperation in the face of adversity. If instead they were to simply ask, 'how do we do this?', or 'how can we make this happen?', they might be met with serious resistance to change. By asking, 'what would have to be true?' they get people thinking and providing information, even if that person or department still believes that something can't logically or practically be done.

With this new attitude, Matt was able to build strong intra-deparmental trust and coordination. Eventually, some of the business requirements were softened and the BlackBox solution was finally truly viable. As a direct product of this hard work, Deseret Book was able to move all order management out of the ERP, and into Solidus. This resulted in the ERP shrinking and not having so much control over every system. They now even have an AWS service data bus that can scale to their needs, whatever they may be in the future.

It was clearly a long journey to get all the various departments to work together in a way they hadn’t before in order to create a fully automated system, but Deseret Book has undeniably succeeded, and is now prepared for any challenge that might come their way in the future. I think we can all learn from their innovations, and should all remember that:

"Positive business relationships and culture are essential to finding and implementing viable solutions to challenging problems"

Now go Watch Matthew’s Talk on YouTube for a deeper look, and real-world examples of these ideas.

Go Back to the Table Of Contents

---

Solidus 2020

Blake Puryear and Jim Kane from Engine

The final talk was by Blake Puryear and Jim Kane from Engine who spoke about where Solidus has been, where we’ve all come from, and where Solidus and all of us are going. Engine is built on marketing, email, and content plus commerce. Their business has developed a way to make growing an online brand a scalable, defined process, and they've done so by practicing and honing those ideas at their own companies in the past. Just like Matthew Redd talked about, Engine has grown to be successful by truly understanding what they're doing, and they have done so by having created successful online brands before.

Jim Kane, the CTO at Engine, started out by giving us a crash course in commerce of the past, reminding us where we have come from. The first age started in 1995 when NSFNET removed its ban on commerce, and companies like Amazon and eBay began to be seen. These were not the websites we know today; there was no real search engine, no tools, no one really knew what they were doing. It didn't matter though, because it was all uncharted territory, and thus everything was new and exciting:

“Novelty can cover over a multitude of sins, you can get away with a whole bunch of stuff if you do something unexpected and surprise people”

The second age of the internet began somewhere around 2005. This was where we saw the rise of Shopify, Spree, Magento, and the like. This shift from websites that sold things, to true ecommerce platforms is largely attributed to google's innovation in online advertising. Before, the goal was to get people to the home page of your website, but now that didn't matter as much, there was no return there. What mattered was getting people to you product page, or pages, this was where you could really make money and be successful.

"The true path to profit became driving people off much more specific terms, those long-tail terms, driving traffic from those straight to either a collection of products or even to a specific product page”

Around this time was also the rise of mobile websites. While we had early smart phones before (such as the BlackBerry), it was not until the first iPhone was released in 2007 that people began trying to optimize their websites for mobile. The BlackBerry was meant as a business tool, the iPhone on the other hand, was built to sell things.

It has now been over ten years since the last age of the internet began, and we are overdue for the next wave. The second age gave us many things we still use today, but what we need to figure out is, where is this all going? What is the next big step, and where does Solidus fit into it?

Jim gave us a very concise picture of what Solidus is today: a flexible, open-source platform with an experienced community and unlimited potential. What Solidus needs is a vision, and a plan to figure out how to realize that vision.

“There’s another mode of commerce out there, it’s a known unknown, that in the next five years will come along and it will not matter at all until it’s everything. So if we can, as a community, make a product that can adapt to that, we can move from survival, past relevance, to leadership - where other products look at what we do and say ‘why aren’t we doing that’ I think that should be our end goal, is to think past being relevant to the things people do today, and question how we’re going to put those things together for the future. 'Skate to where the puck is going to be (Wayne Gretski)'”

Blake Puryear and Jim Kane showing how Engine is looking to the future

At this point Jim handed the talk over to Blake Puryear, who is the Head of Product at Engine, to talk about the future of ecommerce.

Blake began by explaining what the ecommerce landscape looks like today, and what clues that gives us into figuring out what that third age is going to be. Right now we have these two companies who are competing with each other at the highest level: Amazon and Walmart. Competing with either one of these companies takes profound understanding and knowledge. Amazon Basics is engineered to crush brands by creating cheaper copies of the same things. Walmart is fighting back by buying the most successful brands, technology, and thought leaders in order to stay in this war. In both cases, these companies have access to every piece of information about what people are looking for, and what people end up purchasing. This just shows us how critically important it is to have your own content, to own your own brand, on your own platform, on your own website.

What goes along with this, and is just as important, as Blake continues, is to own your data. When you sell through Amazon, or another company that is not your own, they accrue all of your data, and can then use it against you.

"Own and rule your brand"

Now how do we do this? What are companies doing to stay relevant? What's next? What are we moving towards? Clearly it is not enough to be where we are now, even if we are succeeding with what is available to us in this moment.

Engine believes that next wave is going to be augmented and social shopping, or AR commerce, and it is going to happen through our phones. Some companies have already come out with augmented reality apps. Ikea has one for furniture, and Sephora has one for makeup, in both cases you can buy products right from the app, as you are “trying them out”. We can only guess what industry will be next to do this, and I’m sure we won’t have to wait long to find out.

So where does this leave Solidus? More importantly, how can we use Solidus to get to where we need to be? This is what Blake outlined:

1. A modern frontend option, maybe using graphQL as a leaping off point.
2. Admin Extensibility which is important to merchandisers.
3. Taxon model improvements, to re-work how we present taxons to merchandisers
4. API improvements, in order to integrate with trends like AR shopping. Apps such as Instagram and Snapchat are looking for carts to allow in app shopping. Right now, Shopify seems to be the only option, this could be a huge opportunity for Solidus.
5. Event Bus, to make it easier to act on the data we record.

Engine has clearly put a lot of thought and effort behind this, and I think we should all follow suit. What we have to do to succeed is to plan now for what’s coming in the next few years and beyond, 'Skate to where the puck is going to be'. The future is already here in a lot of ways, let's not get left behind. Go Watch Blake and Jim’s Talk on YouTube to learn more.

Go Back to the Table Of Contents

---

What's Next

Southeast Solidus was three days packed full of work, community, and learning. We saw old friends, went on a hike, and even did Karaoke. - All of these incredible speakers devoted so much of their time and energy to honestly sharing their experience and wisdom, giving back to the community through their involvement. Honestly, I couldn't believe how much information there was to unpack in the talks once I really got into it (which is part of why this article ended up so massively long).

I’m truly thankful Karma Creative could be a part of it, and I know it has given us the motivation so that in the long months and years to come, we can truly rise above and do great things. In fact, this conference provided so much energy that I’m already looking excitedly towards the next one. From some casual conversations in the community, New York City seems to be the most likely choice for our next venue. We had 46 people officially in attendance at this years conference, including places as far as Italy (Nebulab) and as close as North Carolina (Candle Science). Let’s triple that attendance number next year.

Reasons To Celebrate

While it’s true things seem a bit muddled right now (what with Stembolt’s acquisition and the departure of several core members), there’s also plenty to be happy about. So before we get our hands dirty talking about what’s next, let’s take a look at just a few of the reasons to be very optimistic:

Hawthorn, Alberto, Greggor, Clarke, Martin, Thomas, and Jordan made incredible progress over the last 3 years making the code more reliable and more secure.

• The API is finally stable.

• Testing and in-code documentation has greatly improved.

• Upgrades are easy (or at least don’t make you pull your hair out).

• Everyone knows class_eval is bad (and we’re making progress getting rid of it).

• More companies are adopting the platform.

• And so SO very much more.

Where we are today wouldn’t have been possible without their truly awesome dedication to making Solidus great. Sincerely, thank you again.

Moreover, Stembolt did a fantastic job executing on their promise from last year’s conference for a new website, branding, and messaging. The site now speaks to both developers and stakeholders alike, nine successful companies using Solidus are now featured, and it’s finally clear what Solidus is to those finding it for the first time.

Better yet, thanks to Stembolt’s spot-on decision to hire Benjamin Willems as a technical writer (and Benjamin’s prolific and dedicated work), we finally have an entirely new set of documentation written specifically for Solidus! (Check out the new comprehensive documentation if you haven’t yet; it still blows me away after all the time occasionally spent looking at the old Spree docs for so many years. Thank you to Benjamin and thank you to Stembolt for deciding to do this.

These tools and improvements are real reasons to celebrate. They help adoption, understanding, and so much more. Their value simply can’t be overstated. And though there’s always room for more work, Stembolt’s committed stewardship over these last few years will be our springboard to what’s next.

We can now honor that commitment and hard work by picking up the torch ourselves.

Our Community Moving Forward

To begin with, one of the things I very much hope to see come out of this conference is the revival of the SolidusNYC MeetUp. In fact, I've already spoken to Eric from Care/of, who has generously offered the use of their office for the MeetUp again. (Be on the lookout for an invite soon!) I’d love to see many other regional meetups too - Why not SolidusLA? Or SolidusSF? Or even SolidusNC? But more than that, we need to take a hard look at where we are going and how we’re going to get there.

One thing is clear: we can get vastly more accomplished when we work together.

The problem is that this is hard to do when everyone is in different places, and impossible when communication is poor or non-existent; it doesn't take a genius to understand that we need more than a conference once a year. Stembolt succeeded in managing Solidus because they took care to invest both time and money: who else but Stembolt paid for Hawthorn’s salary while he worked Full Time on the Open Source Project? Yes, we need some new members in core and at least one new full time maintainer; it seems we can all basically agree on that. But what about the CI servers running the extensions.solidus.io page? What about continued work by a technical writer? Or organizing conferences? Or managing the community?

What next?

Honestly, the first thought that comes to mind is local community meetups. But more importantly, I think these 'local' meetups could be even more relevant if we heavily stressed the remote-friendly aspects. Even if the meetup is called SolidusNYC, perhaps we could think of it more as a location agnostic monthly meetup on Zoom. And if we can successfully engage our geographically diverse community, perhaps we can even start scheduling quarterly remote hack days and a bug-bounty program (as was discussed as far back as SolidusConf2017).

But in many ways, thinking about scheduling meetups is putting the cart before the horse. What we really need now is a new non-profit organization to manage the Solidus Open-Source Project. With Stembolt gone, despite our continued technical leadership from core, we're almost driving blind. Sure, our 4 veteran remaining core members are doing everything they can to manage the project, but what about the community administration? (And this question is especially important in light of the proposed changes in the role of the core team.

And in the case of Clarke and Greggor, what about their new responsibilities and time constraints that come with working at JUUL? While I feel certain they both still care deeply about the project and the community, JUUL's objectives are clearly vastly different than those of Stembolt, who capitalized materially from building Solidus’s brand authority and adoption.

One bright spot here though, evaluating our concerns logically and in terms of urgency: we all should rest at least a bit easier knowing that the code is in the best shape it’s been in for years. And though we need someone on it full time as soon as possible, I feel the even more pressing concern is the loss of an entity managing the community and its administration.

Somberly, but with strong resolution, we must admit that the landscape has suddenly changed.

We’ve got to pick ourselves up. Dust ourselves off. And start doing this ourselves. We simply don’t have the luxury of Stembolt doing it for us anymore.

Moving forward, we have to be realistic, strong-willed, and passionate for what we’ve worked so hard to built. We need to honor the hard work that’s come before today, leading us right here, to this point in time. -- We’re in a new world. It’s time to start living it in.

What we need now goes far beyond the technical considerations:

After looking into organizations like Ruby Central, I think a 501(c)3 may make more sense than just a loosely-defined committee. Moreover, we need this entity so that we can receive funding and have a place to transfer the Solidus trademarks, CI servers, and so much more. All this not to mention more subtle knowledge shares like the Solidus case studies and white papers, which were solicited from the community after the conference last year:

"We’re looking for developers, stores, or agencies to share their experiences and learnings in case studies and whitepapers." From: https://solidus.io/blog/2017/09/25/solidus-community-roadmap.html

Moreover, if we do this right, there's potential in using this organization to not only organize local and global Solidus conferences, not only pay for a full time maintainer, but also to truly lead and revitalize the Solidus community for years to come, updating it for today’s technology and keeping it relevant.

A Look At Past Stewards

The way I see it, each open source project also needs a company that helps organize joint efforts and acts as a shared community management entity. Think of it like this:

Spree had SpreeCommerce Solidus had Stembolt (until now) and now, Solidus needs to have [the new 501(c)3].

The core team alone isn't enough. We’re missing an important evangelistic and administrative function.

SpreeCommerce did a fantastic job of organizing conferences, directing development, running a partner program (featuring a whole list of agencies that work with Spree on their website), and importantly, promoting examples of sites currently built with Spree - among many other things.

Stembolt also did a fantastic job organizing conferences. Moreover, as I’ve said, they did the critical work of job stabilizing, securing, and improving the code base; these accomplishments shouldn't be understated. On the other hand, unlike SpreeCommerce, for a long time, they also only listed 3 clients on their website (Raden, Goby, and ME) and they never rolled out a robust agency partner program, despite its announcement at SolidusConf2017. And yes, there was also a Solidus website, but until last year, it only mentioned 2 Solidus stores: Lost My Name (now Wonderbly) and Bonobos. Even to this day, despite now listing 8 new companies currently running Solidus, the website still offers no agencies that work with the Solidus platform. [But what else could you reasonably expect? After all, Stembolt was a for-profit digital agency and I think they were justifiably simply looking out for what was in their best interest.]

Goals for the Non-Profit

So where does that leave us now? Honestly, I think the best thing we could do is form the new 501(c)3, and to define our mission statement, bylaws, and goals. From there, initial fundraising will be the next hurtle; and in short order, we’ll be making significant progress towards our goals, as we truly rally together as a community.

To get us rolling, here is a list of proposed goals for the non-profit. They are specifically open to feedback from the community for revision or even replacement. Beyond the direction in our technology coming from the core team, we need to find direction in our organization. Agreeing as a community on a set of core tenants, such as these, will be a true cornerstone of our bright future.

Proposed Goals:

1. Fundraising - Secure endowments and other investments from the community
2. Yearly Solidus Conf - Organize SolidusConf each year
3. Code - Organize project roadmap and implementation efforts through collaboration with and at the direction of the core team
4. Documentation - Continue documentation for developers, administrators, and stakeholders/decision-makers
5. Current Stores - Feature a much more comprehensive list of companies running Solidus on the solidus.io website, including case studies and white papers
6. Partner Agencies - Create a partner program to list agencies on the new company website, probably charging them a yearly fee to be featured on the site, perhaps offering a few tiers of agencies based upon their contribution level
7. Support - Ensure that requests for help, and other community inquiries, such as questions asked in the Solidus #support slack get appropriate attention; in a nod to both Daniel Pritchett’s and Peter Berkenbosch’s talks, consider providing a chatbot or even an automated phone number for people and companies inquiring about the platform, and/or even a ticketing/support system such as Help Scout - eliminate the feeling of 'shouting into the void' when asking for support now that core members are less active in slack. A quick improvement would be moving support questions into StackOverflow so we have an easily searchable history.
8. Community Engagement - Increase organic contributions and community activity, secure pledges for dedicated open-source development time
9. Update and Support Extensions - Decide and implement a new standard for how to write and use extensions, maintain extensions.solidus.io, and support other extension related resources like Nebulab's Soliton
10. Regional Conferences & Meetups - Encourage and support regional SolidusConfs and Meetups (based on funds, interest, and people stepping up to help organize)
11. Adoption - Promote the adoption of Solidus within the business community, improving visibility and accessibility to decision makers and marketers
12. Communication & Knowledge Share - Post regular new updates on community and project issues in a well maintained blog, and, solicit writers from the community to contribute biweekly Solidus-related articles sharing knowledge, tips, tricks, and real-world experiences

Aligned Incentives and a Return on your Commitment

We need to nurture this community that helps make us all so great, and I can’t see any reason why we wouldn’t do that. Still, when practical decisions must be made, business value and tangible benefit hold highest merit. Thus, the following discussion:

We all benefit from the incredible work that has gone into our platform, that part is easy to see. What’s harder to immediately understand is that despite our diverging objectives, we are all going to have to face many of the exact same challenges in our Solidus applications, in the coming days, weeks, months, and years. The whole point of making upgrades easier was to try and allow shops to more seamlessly take advantage of the incredible work the community continues to contribute. Shops still stuck on heavily customized versions of Spree 2.4 drool just thinking about all that community work. They know they’re missing out but are often paralyzed by customization so heavy that their only choice is to completely replatform to Solidus, rather than 'simply' upgrading. And despite all this, they still try desperately to get back to being in sync with the Solidus codebase. That’s because aligned incentives are awesome. Maybe you contribute 20% of a single developer’s time for an entire year; sounds like you’re losing something, right? Think again: what if there were even just 5 other companies doing the same thing? Suddenly you’re getting back a 500% percent return on what you’re contributing.

A lot of this boils down to some form of the Prisoner’s Dilemma. More specifically, we’re probably looking at something similar to the special case of the Donation Game. Adapting it slight to our purposes, the resulting model reads something like:

By choosing to cooperate and expending documentation and contribution costs 'd', one developer can document their part of the system sufficiently so that the other developer can readily use the first's work, receiving benefit 'b'; on the other hand, if one developer chooses to defect then this documentation or the required contribution is lacking, and the other developer has to expend higher costs e to derive the necessary information, implement the required feature, or fix the corresponding issue alone, with b > e > d. Defection essentially means offering nothing and working only on your own code, leveraging the previous and on-going work of the community. The payoff matrix is thus:

If you’re interested in further reading on this topic, I highly suggest the following Research Paper on the topic. It was a very interesting (albeit a bit dense) read:

Eckert, Daniel & Koch, Stefan & Mitlöhner, Johann. (2018). Using the Iterated Prisoner's Dilemma for Explaining the Evolution of Cooperation in Open Source Communities.

Software development, and especially open source projects, typically involve repeated interactions between participants and groups of participants. We propose to analyze this situation by means of the standard model for the evolution of cooperation, the iterated prisoner's dilemma. The prisoner's dilemma is a well-known model for a two-person game, in which each side can choose to either cooperate or defect, and in which the payoffs are arranged in a defined hierarchy (e.g. the highest payoff is achieved by defecting while the other player cooperates). As a first step, the prisoner's dilemma needs to be formulated for the open source development model, i.e. what constitutes cooperation, playing defect and payoffs. Then, computer simulations using a population of stochastic reactive strategies can be applied, using a strategy's payoff as fitness measure for determining its frequency in the next generation. As a further extension, the effects of misinterpretation of other's behavior can be included into the model. We will discuss which insights into open source software development can be gained by applying this model.

Link: https://www.researchgate.net/publication/228666257

What this really all boils down to is this: it’s in everyone’s best interest if we decide to cooperate. Better yet, the data indicates that even only a few altruistic contributors can have a disproportionately large positive impact on the behavior of the rest of the group, and that there is a tendency towards even more widely-pervasive altruism as the project matures.

Some of the challenges they highlight most strenuously are miscommunication, misinterpretation of actions, and failure to establish strong social norms and codes of conduct. Unfortunately, these challenges are exacerbated when you have actors at different organizations because of skepticism towards the ‘alien’ actor and a lack of trust.

To me, the message is clear. We must work hard to improve our communication. We must be purposeful and diligent in thinking about how our actions are perceived by the community at large. And we must codify the standards of behavior that we all expect from one another.

But most importantly: We must build trust.

Trust in the community. Trust in one another. Trust in ourselves.

• Trust that the code we contribute back will be used, even if we feel it might be too ‘specialized’ to be easily adapted by other community members.

• Trust that our questions and issues will be answered (and that someone else will be interested in the answers and solutions we eventually find).

• Trust that there’s enough business to go around that we don’t need to compete with one another for it.

• Trust that contributing back to the community won’t mean giving up some kind of proprietary business advantage.

• Trust that we’ll get more back when we genuinely give more back too.

• Trust that Solidus is here to stay.

• Trust that we’re making the right decision to contribute rather than defect.

We don’t have to pretend that the only motivation to give back is altruism. When we work together, we avoid the Tragedy of the Commons and everyone wins:

Like roommates sharing a home, if we all take a minute to contribute (by washing our dishes after using them), then the home runs like a well-oiled machine. People are happy. They trust each other. They see others contributing and they feel pressure to do the same. Moreover, they feel pride and even take pleasure in giving back because they can feel they're part of something bigger than themselves. Maybe they even have time and newfound motivation to do more than just the minimum, more than just washing their dishes.

I know I don’t have to even describe the alternative, but with no cleans dishes, even close relationships quickly become full of resentment and completely fall apart. People stop trusting each other. They start buying paper plates. Eventually, they just move-out.

Today, by some miracle, our home is still relatively spotless. Let’s keep it that way. -- True, a few things do need our immediate attention; but thanks to those Stembolt guys (who just moved out to a new place across the street), we haven’t had to do very much cleaning in quite a long time.

It’s time for all of us to step up and do our part, and if the conference is any indication at all, we are ready.

A Call To Action

By choosing to support Solidus with our time, money, and code, there’s no question we can help each other realize enormously more value for our businesses than if working alone. The continued maintenance and growth of the platform is genuinely in each and every Solidus store’s best interest.

Beyond the formality of forming a new entity, we need community members to step up and give back. Our first major challenge will be securing enough funding to add a full time maintainer to the project and pay for running the internal operations of Solidus (such as the CI servers, the Github Organization account, etc). Beyond that, we need a community manager, a technical writer, and an administrator. -- We need more than just enthusiasm; we need commitments.

And speaking of commitments, I want to strongly voice a final consideration here:

Those companies and developers who meaningfully support the community in this new effort will be the same ones the community will care most about listening to in the future direction of the platform.

We clearly must align ourselves such that the platform continues to develop in the directions most favorable to the community’s most altruistic and generous members. In other words, we must promise to honor any serious commitment to the platform with a commitment of our own towards our collective alignment.

Now is our time to act. This is absolutely critical if you care about the platform.

Please comment below, or get in touch via slack or email.

Go Back to the Table Of Contents