The Changelog: Software Development, Open Source - Spree and Ecommerce in Rails (Interview)

Episode Date: November 3, 2011

Wynn sat down with Sean and Brian from Spree to talk about ecommerce in Rails, SpreeConf, and their recent $1.5M funding round.

Welcome to the Changelog episode 0.6.9. I'm Adam Stachowiak. And I'm Winn Netherland. This is the Changelog Wikipedia for what's fresh and new and open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also on GitHub. Head to github.com slash explore your funds, some trending reposts, some feature reposts from our blog, as well as the audio podcast. If you're on Twitter, follow ChangeLogShow and me, Adam Stack. And I'm Penguin, P-E-N-G-W-Y-N-N.

On episode this week, talk to the guys over at Spree, Sean and Brian, about the recent funding round and the latest developments with Spree. You know, this is some really good news for the Upsource community. I mean, on top of this funding as well as AppCelebrator's recent 15 mil, this is exciting news. Yeah, it's fun to watch projects get some backing, allow them to do some things they normally wouldn't get to do. Spree Conf is one of those for the Spree community. There's going to be a conference February 15th, 16th in New York City. I hope to see you there.

Excellent lineup of speakers. And if you really want to make it, it's not a bad price out of $99 to get registered. That is a cheap conference. That's a really good conference ticket. Excited to be there. It's a fun episode this week. Should we get to it? is a cheap conference. That's a really good conference ticket. Excited to be there. It's a fun episode this week. Should we get to it? Let's do it.

I'm chatting today with Sean Schofield and Brian Quinn from the Spree Project. So, Sean, you first. Why don't you introduce yourself and your role over at Spree. I'm Sean Schofield. I'm the creator of Spree and co-founder of Spree Commerce and CEO at the new company that we've just established. Brian, what's your role over there? I'm the CTO of Spree Commerce Inc. and a longtime contributor to Spree. So for those that don't know Sean, why don't you give a little background about the Spree project and. and a long-time contributor to Spree. So for those that don't know, Sean,

why don't you give a little background about the Spree project and what it is? The Spree project is an open-source e-commerce platform for Ruby on Rails that started about a little over four years ago and an original name was called RailsCard. So it's kind of evolved to this point, and I can give you a little more background later if you want to know more about the history, but that's the gist of it. How long ago was it RailsCart? Over four years ago. I think the first blog post to the Spree user mailing list was a little over four years ago. It's gone, I guess, through a couple of transformations. It's now a Rails engine, right?

Yeah, yeah. We've been, we've steadily kind of evolved with Rails. And in some cases, maybe even, you know, influenced the direction Rails has gone in, you know, subtle, but important ways. So we were definitely a proponent of more engines and that kind of functionality in Rails. And the core team, you know team listened, which was good. So how big was the move to Rails 3.1 for Spring? Brian, do you want to handle that one since you did the best? Yeah, sure. It was a pretty big job because prior to Rails 3,

we had been using kind of our own version of extensions, which were basically engines, but they were kind of shoehorned into Rails. So we had a very kind of rough boot process and it was a pretty rough experience. So with the move to Rails 3, then we were able to basically back out all that code and just completely embrace the Rails 3 style of engines. So yeah, it was a pretty massive change. I think it started around uh railsconf in baltimore it was the first time in the first railsconf baltimore when we actually started working on it when we managed to get some time together at the uh at the excellent

bowconf there so um yeah it took uh i think we were about nine months actually working on that release until we got the 0.30 release which which was the first one to support Rails 3. And Rails 3.1 was almost as complicated, it turned out. Yeah, absolutely, because the asset pipeline and other features like that really took us a while to get that integrated. And I think we probably jumped on the Rails 3.1 migration a little bit too early because the core team were still settling down on exactly what Sprockets was doing and what features were where.

We were chasing the mark for a few weeks there until it settled down, but it seems to be pretty solid now that our latest 0.70.1 release is fully Rails 3.1.1 compliant. The Rails 3.1 asset pipeline is a two-edged sword. It streamlines a lot of the

asset generation and makes assets first-class citizens of the project, but also it comes with attacks for developers, I guess, during development mode where it's much slower. Yeah, absolutely. And like one of the great things about the asset pipeline and how it works with engines is it gives you great like modularity in that, you know, an engine can bring along a little piece of JavaScript or a CSS file, and they can all just marry in together into the final assets for the project.

So it's definitely phenomenal in that respect, but you do pay a price in terms of development performance. But there is Raycast now that will allow you to pre-compile your assets if you're not working on them in development mode, so you can completely pretty much remove the penalty for performance there. So Rails engines, I guess for those that don't know, take advantage of open types in Rails so that you can include models, views, controllers from an engine

and override them in your own project and really exploit that feature of Ruby. Talk a bit about how many different touch points are in the application that you can customize to suit your needs. Yeah, well, like you said, an engine is really just a Rails application. So it provides that mechanism

to bundle in all your controllers and models. And then basically we kind of add in this extra layer that we call decorators, which is a pretty common idiom for development, where you can basically take a class, like say the product model, and open it up, change whatever methods or add methods

that you need to add to it, extend it with new associations or whatever. So your host application takes in Spree as an engine and then can bend it to your exact requirements. And then there's a huge collection of extensions, like third-party extensions that are available and listed on our website that you can go and pull down extra features like wish lists and social integration. There's countless other extensions that are already written. So you can also tie those in at the same time into your host application and customize it exactly the way you want to. So beyond that, Spree is also not just a monolithic gem.

It's made up of parts that you can use a la carte, right? Yeah, and I just want to add on the engines thing. I think that the engines development in Rails was super important. And I think we're only just starting to see some of the benefits of it like um they started out i mean there there was a project called engines like um that was a separate sort of unrelated project with the same name um that you know initially i think was disparaged a bit you know by dhh and others they didn't want that part of rails but ultimately they came around to something that was pretty close to what people were doing

outside of the Rails project. Radiant, in particular, had adopted an extension mechanism that, you know, that influenced us, and that, in turn, influenced, you know, the direction I think that the Rails team went. But we're only just now starting to see people really kind of, I think, the Rails team went, but we're only just now starting to see people really kind of, I think the documentation was fairly limited and just, I don't know, it just took people a while to kind of grasp what the power of, you know, engines really

means. And now we're starting to see some of the more major Rails open source projects moving to engines. Like, you know, Devise has been, I guess, an engine for a little while, but, you know, projects like Radiant and Refinery and now there's like this forum and Rails Admin, I'm starting to see more and more engines and now we're going to start to see what can happen when you combine them all. And I think that's, you know, that's been a huge, you know, development for Rails. You mentioned Devise, I guess Devise is part of Spree with Spree Auth.

What other popular plugins make up the architecture for Spree? We're using, is it Kaminari for paging? Yeah, we were using Will Paginate dependencies because Rails 3 actually helped us in that way because so many things broke at Rails 3 and then we just didn't, you know, we ended up kind of coming up with our own Rails 3 compatible solution or moving to, you know, that was a big consolidation of our dependencies because a lot of older projects just never got upgraded, never made it, you know. That was like, Will Paginate finally kind of got there, but it took a long time.

So that's why we moved to Kaminari and, and SearchLogic, you know, others, we just kind of end up abandoning because, you know, they had stalled out a little bit, I guess, in terms of momentum. And so that was a period of consolidation for us. It makes our job easier too, as we're, you know, migrating between versions of Rails, the less dependence we have on third-party gems, the less kind of forking and waiting around for libraries to get updated

or, you know, taking on a big job of updating a library. Like for our Rails 3 migration, we were using James Gullick's resource controller and we had to port that to Rails 3. And that was in itself one of the biggest jobs of the Rails 3 migration. So as we're slowly kind of taking away as many dependencies as possible and we're trying to keep Spree

almost as simple a Rails application as possible to make our migrations easier between versions. But we do use a couple of other interesting gems like State Machine. Oh, yeah, yeah. It's a good extension. We use it for our checkout kind of State Machine, basically. We also use Active Merchant, of course, from Shopify,

which is a good payment gateway library. Yeah, Active Merchant and Plug-in-a-Week State Machine are good about updating, you know. They're very active communities, and they're good about updating to the newest Rails, so we don't have a problem depending on them. So quite a number of models here in Spree. If you go to the Spree Core app models folder, I guess the good news is you can customize those if there's overlap with your application.

I'm curious, for most people when they're creating a Spree project, is it adding storefront features to an existing application, or are they starting with the store and building an application around it? It's primarily been used up till now. You know, it's primarily worked best as a standalone store that maybe then you add features around. I mean, that's kind of been the bias, I guess. But we are, you know, there's no reason why that needs to be the case. There have been cases where there have been really mature, um, Rails applications that

Spree has been integrated in, but that's always been more difficult than it should be. Um, but again, with engines and now namespacing that's supported in Rails 3.1, um, you know, there's some really good opportunities to kind of break that assumption that the store is going to come first. So we're definitely very interested in being able to integrate with Refinery, Radiant, browser, CMS, all the different open source CMSs. There's been a lot. Since I started Spree, one of the first questions on the user list was like,

can I combine this with Radiant? And people ask about every other week for that functionality. So, um, the good news is that that will be a lot, that will be a reality soon. And, um, because with engines, we can just, you can just drop them in, in any particular order and it doesn't matter, but that's a pretty complicated exercise to really, because spree is not some little widget that you drop into WordPress. Like it's a huge full-featured e-commerce engine, and there's a lot. There's authorization and authentication and admin stuff, reporting, and there's just a lot of interdependent pieces. So Rails is now sophisticated enough, and we have now refined Spree enough so that this should be possible.

So Spree's had a couple, I guess, corporate sponsors over its lifespan, but just recently you guys formed Spree Commerce, the company behind Spree. So why don't you talk a bit about that news? Sure. Well, I began Spree. Spree began when I was a freelance consultant. So it really – and it really still solves that – it's still working on solving that problem that were interested in what we were doing. And, you know, and it kind of being associated with that project brought them some, you know, business and, but then really became big enough that I could justify kind of starting at Railsdog, which was a, well, Railsdog was originally a blog and named after my dog. And then it just sort of evolved into a company. I ultimately didn evolved into a company i ultimately didn't want

a company that i didn't own or control to be sort of affiliated with the project anymore so i just set it up as like i'm going to kind of self-sponsor the project and that was like sort of an intermediate kind of step and but then it quickly became like wow there's enough interest in here i could probably just start a consulting company just around doing Spree work. So it kind of morphed into RailsDog, the consulting company, and we did that. And Brian is a longtime contributor through open source, and then he joined us at RailsDog. And so he was with me at the very – he was like the first employee at rails dog. And, um, and then, and then we just recently started this new company as a vehicle for the investment.

And the separation there is really consulting and rails dog is still like a consulting company, the new company, um, besides, you know, investors aren't interested in consulting. They didn't really, you know, help us build the consulting business. So we didn't really feel like we needed to cut them in on that. And we wanted the ability – the whole point of getting the money was to really have the ability to focus on Spree and the product in the community and not the short-term kind of needs of clients. So there is this new company, Spree Commerce Inc., which is now a custodian of the SPRE source code and the current benefactor. So when you mentioned getting the money, you're referring to the recent 1.5 million seed funding round led by True Ventures? Yes, I am.

That's exciting. Yes, yes. So how are you going to spend that? Well, we've got a lot of different ideas. I mean, believe it or not, like the money can be spent and can be spent fairly quickly if one is not strategic about it. But our main thing is like there are a lot of, I guess, public goods. I have an econ background, so like a public goods kind of context or things that you know the free market would not take care of by itself like so i.e you know clients aren't going to pay for better documentation

um because once that their documentation exists everyone can benefit from it and they don't you know they're not going to benefit proportionately to what it would cost to create it so you know but once we create a really great ecosystem, like with documentation and, you know, videos and other tutorials and things like this, then everybody can benefit. So that's an example of where, hey, you know, we definitely plan to invest a lot more. I think we have pretty good documentation for an open source project, but, you know, now we can, you know, really put more into documentation,

training, answering, you know answering questions on user lists. We can dedicate a lot of resources. So that's the first priority is to continue to nurture our growing ecosystem. And we have some ideas we can talk about a little bit later in the conference. Like I mentioned before, we got on that thing about a conference and some other ideas for the money. So, yes, let's talk about that. When's the, uh, the big date. So we're going to do our first, um, ever SpreeConf in New York city next February, it'll be February 15th and 16th. And so, um, the site should be up by the time this airs,

SpreeConf.com. And, um, is this geared towards developers or business folk? Yes, it's geared towards, I think it's geared towards developers, but also, um, it would be appropriate for business owners that want to learn, um, more about spree. There'll be, there'll be something for everybody. There'll be opportunities to learn there. The first day, the 15th of February will be training and we're going to do a full day of training on, you know,

we'll probably break it up into half a day of rails and a half a day on, on spree. And then the second day will be talks, um, the, the training. So, you know, if you want to learn more about spree, there'll be the training that we'll have a hackathon, you know, all the spree, well, our most of the spree core people will be there. Myself and Brian will be there and, and, uh, there'll be a couple of talks like, you know, a little bit more all the spree well or most of the spree core people will be there myself and brian will be there and and uh there'll be a couple talks like you know a little bit more geared towards spree but then there'll be a lot of talks that are just going to be talking about general uh topics of rails interest so if you're in the new york city area or you want to come so when you are scheduled to speak as well i I would love to. Yeah. So, um,

so, but we haven't discussed the topic, but you know, we've penciled you in there. So, you know, like I think maybe we'll try to maybe put things in a little bit of a spree context when possible, but you know,

I, I'd like to see some talks on coffee script and, you know, um, we have a guy that's probably gonna do talk on recommendations engines. And I mean, you know, recommendations and the kind of algorithms that go into that and some of the

kind of just general problems behind that sort of area are, you know, I think would be of interest to anybody, you know, doing rails work, not just free people. So it's going to be kind of a crossover sort of thing. Our community isn't large enough really to warrant like a three day rails conf extravaganza. And we're going to have some cool speakers um and uh interesting people there so brie pettis is going to be doing our keynote speaker he's the ceo of makerbot so um really cool company is really popular with the tech nerds and

um he's gonna do a demonstration and talk and so i think it'll be cool just to go and you know uh see him do his thing. But, you know, Scotch A Cone and some of the other usual people that you see at the, you know, regional Ruby conferences will be there too. So, and GitHub's throwing the party afterwards. So definitely come by and see us. Definitely worth it. I see Sticker Mule is in your success stories showcase on SpreeCommerce.com. Yeah, the Sticker Mule guys will be there too.

If you've ever bought stickers from them, come. Love the stickers from Stick mule yeah they're they're they're probably our favorite spree client i mean um we love all our clients at rails.org so what's the largest uh and installation that you know of for for spree okay so uh let's. Well, the largest – there are two large ones that use Spree to some degree or another. So one would be Shoe Dazzle, and Shoe Dazzle is a huge – I think they're doing something. This is not inside information, just whatever. It's rumored to be $100 million dollars a year in sales and shoes and that's kim kardashian's like shoe company so they had a rails custom um a custom rail solution and they moved to spree quite a while ago like an older version of spree and they've customized it heavily since so i mean it's not like oh if you installed spree you will be able to build shoe dazzle overnight or whatever. I mean, obviously a lot goes on top of it, but that's like a pretty big name client that's using it.

The other is Second Life. Yeah, Second Life. So they are using a very customized version of Spree, even more so than ShoeDazzle. But one thing I know that's fairly intact um and again these guys started early um you know when spree was a lot rougher one thing that remains definitely intact i've heard and um the second life installation was uh the data model so you mentioned all the models and you kind of pick and choose but interestingly we get a lot of compliments on oh the data model is really good like was the, that was like a big part of what they decided to use, um, on that particular installation.

But, you know, so we can go, so Spree is certainly suitable to either jumpstart or actually run like a very big, huge business. But, you know, there's also, we've got people who do, you know, a few thousand bucks a month in sales. And then I think a good, a good standard, you know, be 25, $50,000 a month. There are a lot of stores that run in that range, some several hundred thousand. I mean, I won't get into the, you know, names and with figures, but.

So what sort of ecosystems cropping up around Spree for extensions and themes? Well, the, the extension kind of ecosystem is pretty vibrant and pretty popular right now. If you go on to GitHub and just search for repositories, they start with Spree underscore. I think they get about 600 different repos, and that's not including Forks. Because Spree has supported extensions since one of its earliest versions,

there's always been a lot of activity there, and pretty much every problem that you need to solve on a regular basis for an e-commerce store has been solved for one version of Spree or another. I guess one issue there really is, you know, with any open source project is as the core product rolls forward, not all the extensions follow along. So there's obviously a big method and overhead there to uh to support you know the huge community of extensions but we maintain a pretty large collection of about 20 extensions that we classify as official extensions that you know uh get used an awful lot by by the majority of stores but yet don't warrant being in core itself stuff like um spree social which gives you integration with omni auth so you can log on with facebook and Twitter and other all-out sources like that. There's Spree Active Shipping,

which integrates with FedEx and UPS and USPS and all those other shipping APIs. There's countless others, PayPal Express-related products. You name it, basically. Somebody has already written an extension and we've taken over a few of them as important extensions to maintain them going forward.

So we also have a project called Rails Dog Radio, which is kind of a large sample store of Spree. So it uses Spree, the core product, and then I think about six of the official extensions and then a custom team as well all rolled into one and as part of our upgrade process for every version of spree we basically we use it for dog fooding so we go and we upgrade the uh the rails dog radio store to use the latest version of spree and then that kind of gets us starting and gets us started on uh upgrading all the the

official extensions so uh the source for the ResLog Radio source is available on GitHub as well. You can, we give you links for that and whatever. And yeah, so the ResLog Radio

team is one of the first kind of, the teaming is a relatively new feature in Spree. It only came about with the, well,

with 0.70 already, so which is only a couple of weeks old. So the ResLog Radio team is one of the first teams built on Spree, and that's something we're actively looking at is building out more team extensions.

But in Spree terminology, a team and an extension is the same thing, except a team really only changes the front end, doesn't bring any logic with it. Yeah, so I wanted to go back to a couple of things Brian just mentioned because it ties into the venture funding that we discussed before. You know, the Rails Dog Radio, which is – so that is the official, like, online demo. So, like, it's like a fancier – you know, Spree is pretty bare bones when you install it, and intentionally so. So you can kind of add the theory as well. You can just tweak the UI with a theme and add extensions that you want.

But, you know, there was two problems with just leaving it that way. One is that, you know, it's hard to tell people, like, but it can do so much more, just trust us. So, you know, we wanted to kind of sort of demonstrate. And then also people, you know, didn't want to – and also I think, you know, it was helpful to kind of show, give people a jump start. So, you know, we decided to build this RailsDog radio and make it open source.

So that's all open source, but you can see it online, and then you can also just get it from GitHub and use it as a starting point. All it is is a gem file pretty much that references a bunch of other Spree engines, and it kind of shows you. It's like a reference implementation of Spree, I guess. But it took us a long time to do that. We did that through RailsDog and with some of the proceeds, basically because we had to pay the engineers who were working on it and the artists who designed it and things. We had to – it took us a long time to get to the point where we could do that because we were just so busy taking care know, taking care of our clients, which is, you know, what we should be doing when we're consultants. So, you know, that would have

gotten going a lot faster. And then there are things that still need to be done, which is like, Hey, we need a lot more themes. We need better curation of the extensions. Like there are, you know, you know, outdated versions of almost everything you need at least, but, you know, you know, will it run on my version of spree that I need, you know, maybe, maybe not. And so that's definitely gonna be a point of emphasis for us, you know, and again, you know, having no, no client is going to pay for that. So that's, that's something that that's really important, but, uh, and now we can do. Have anyone actually trying to buy things from rails, dog radio and wondering why other products don't. Yeah. Occasionally, um, we try to warn them their products don't ship. Yeah, occasionally.

We try to warn them that it's not a real store. I don't even know if it takes real credit cards. I don't know, yeah, but sorry. We'll issue a refund promptly. No, there's really, nobody's cards are getting charged, so yeah, I know, whatever. We do our best. So you do have, this is the online sandbox, but you do have

an admin view of this too. If you want to unfurl your own sandbox, you've got a script that will crank up a new Heroku instance for them and email it. Yeah, yeah. So now that won't – so you won't get a RailsDog Radio one, but maybe we'll change that in the future. But the thing with RailsDog Radio is it's a huge actual product. So our friends – I should plug them. Okay, so if you do want a satellite radio, you should go to tssradio.com and, um, you know, they were nice enough to donate the product

inventory. So, you know, we really, a big problem with e-commerce is not having enough real data. So we used all, we use a ton of real product data, um, and SKUs and things like this just to make it kind of realistic. And so that was nice. And eventually, you know, people have been asking us, we just have to sanitize the data to make sure there's nothing in there that shouldn't be in there. And we'll probably make that open source to the data set. But yeah, so people want to be able to see the backend admin functionality. And that's often very difficult.

But all you have to do is plug in your email. And like you said, it'll spin up a Heroku instance. It won't be rails.radio, but you'll be able to log in and, you know, like a lot of these demos for open source stuff, you know,

just like spree included, it used to be like every half hour, hour we wipe out the database, you know? So this way you get 14 days to kind of just play with it. And, you know, your data and your work won't be wiped out and you can kind of just show it

to a client, noodle around on it, you know, just to get an idea for how it works. So the only thing I was disappointed with, I kicked the tires of that last night, is I guess I was expecting, since I used the same email address, to have ownership on the GitHub or the Heroku repo in that deal. That would have been a nice touch. Yeah, there's one tiny technical flaw there is we use Amazon S3 for the image attachments. So our S3 credentials are tied into the account. So we haven't quite put the effort into work around that solution where we can transfer ownership to a different account. But that's definitely something we might look at in the future. So Brian, before we started

recording, we were talking a little bit about Spree under the hood, and one of the components was one of your projects, DeFace. Why don't you give a quick overview of what it does? Sure. Well, yeah, so DeFace is like a generic Rails tree library that basically solves a big problem we had. Well, not a big problem, but a problem we had with Spree, earlier versions of Spree, where obviously it ships with a large amount of views for all the backend and for the relatively basic front end. And a lot of times, when you're customizing Spree, you just want to make one small change. You want to add in an extra button here, or add an extra column to a table or something relatively trivial and while we did have kind of

helper hooks kind of dribbled all over the place in the views to try and try and help you kind of hook stuff in there invariably it was never in the right place and like during my time at rail dog i literally designed hundreds of spree stores and like constantly putting my head up against this problem so this was the face was kind of my pet project to solve my own scratch my own edge to the true open source sense so what the face lets you do is uh well first of all it allows us to get rid of the the hooks from the views and basically you can um target a a view in rails and basically um using css selectors you can target any element on the page, be it a div tag or actual ERP Ruby code itself, and you can substitute that then with a different snippet of code or render a partial into the file.

It's a pretty complicated process. It took me a while to figure out exactly how to make it work, but under the hood of the face it basically hooks into the um action view uh part of rails and when it's actually um compiling the template from the file on the disk it hooks in there and grabs the source and basically does some parsing on the source of the erb file and converts it into basically x that then is passed off to Noku Geary. And then you can use all the power of Noku Geary's amazing CSS selectors to target anything within that file and make changes. You can insert after, insert before, replace, replace contents.

You can set attributes on tags. You can just completely remove something from the file. And then it kind of decompiles it back into proper ERP code and then just hands it back to Rails. And then, you know, Rails renders the view accordingly. So it basically removes the need of having to, you know, copy over an entire view to customize it. And it also gives you the ability then to kind of layer up changes

one after the other. So, you know, say like this free social extension could include a link to log in via Facebook. And then the Rails Log Radio team can come along later, retarget that override and make some more changes after that to, you know, change its color or whatever, add in some extra tags or something like that. So it basically makes views as customizable as possible without ever having to touch the underlying view. And the benefit there is that when Spree upgrades between versions, you don't have to go back and look at all the views you've overwritten and try and merge in the changes or anything like that,

provided that the original HTML hasn't changed too much. Your hook will still work and it will still catch on to the same place in the file. And the face then also gives you this kind of what I call upgrade protection where you can pass in the original markup that you're replacing. So if the face notices a change, if you upgrade spree

and then when the override is happening, the face notices that, well, the original HTML doesn't match what you say it should match then it will warn you so you get kind of built in protection that way too. So it's essentially monkey patching your views basically yeah it's like taking the

decorator pattern for you know it's like a classy battle for your views yeah that's it exactly yeah. So sadly the readme says ERB only no Haml support. Yeah, well, there's a big issue there. It's impossible to get Haml into some sort of an XML representation that Nokogiri could handle.

So that kind of sank that possibility, unless somebody is willing to write a CSS selector library for Haml in maybe a while before DeFace supports it. But we are looking at allowing you to supply Haml as the replacement markup. So that may appease the Haml gods. Yeah, so you could just say, hey, replace this section with this snippet of Haml.

Basically. Yeah. Gotcha. Now, I'm finding I'm using a lot more engines and projects these days and it seems like the common uh thread around all of these is i want to turn off the entire view layer from a lot of these projects i'm finding that models and controllers are pretty well thought through but views tend to be very project specific and a lot of times just not very well

written yeah that's that sorry sean that's technically true for spree as well like and and a lot of times just not very well written. Sorry, Sean. That's technically true for Spree as well. And we kind of make that point. We keep the front end of Spree very, very basic because everybody wants their store to look different. So we just have a very semantic, very basic, easy to start front end in terms of views that you can customize.

But invariably, most people will almost throw that completely away. But then the inverse of that is the backend. You know, it's a very full-featured backend. It looks pretty nice, and people don't really care too much about what their backend looks like. They just want to get in there and process orders and, you know, deliver shipments and edit products

and do all the fun jobs of running an e-commerce store. So that's where DeFace really shines in that it lets you just, you know, make your small little changes to the admin side of things without, you know, shooting yourself in the foot for future upgrades, basically. So we've actually, when kind of in tandem with this DeFace and RailsDog radio effort, we actually took the views, the front-end views in Spree. They were already pretty plain, and we made them really plain. In fact, when people started seeing the code, they thought that the asset pipeline was broke because there was like no styling. And,

um, you know, we're going to have to put, in fact, we're going to have to put some kind of theme, you know, we're going to have to just put a default theme in there just so people don't freak out totally when they see it. Because, you know, we really went with a very semantic HTML. We took that to the extreme and was like, all right, you know what? Like people, this is, the views really are a throwaway. So, but if we made them, you know, basic enough, you could probably leverage them with a theme. So that's what we've done.

So we totally, I agree that the front end stuff, particularly customer facing stuff is way too specific. I mean, it's not even a question of writing a good view. It's just, you know, the needs are just too specific for any one particular store. So we assume you're going to throw that away. So I want to imagine a big piece of this project is just communicating news out to the community. So you mentioned hiring someone for that role. What's the latest on that? Yeah, so we're really pleased to have hired a new community manager.

So starting in a couple days here will be Ryan Big. So some of your audiences at least will be familiar with him. Oh, yes. So Ruby Hero award winner last year and rails three in action, et cetera, et cetera. And, you know, so, um, I mean really the ideal, uh, community manager, you know, when I look at the criteria, so we were very fortunate to get him. He, he was working on a spree project when I contacted him and, uh, we just happened

to kind of catch him at the right time. And, you know, but his dedication to really making open source awesome and helping people learn and all of that. I mean, you'd be hard-pressed to find a better person for that job in almost any programming language. So great guy, very technical, but also very helpful and supportive. And we really want to try to – so hiring a community manager in general was an effort – was a goal of ours with the funding. And interestingly, you'd be surprised that the idea came from somebody sort of on the VC side of it, right? Like a business-type person told me, hey, you should hire a community manager. So it's cool that it's not all like, and we were like, yeah, absolutely. I mean, and Brian and I are really, you know, doing a lot of the running the community.

We have a couple other core members that help as well. But this guy, you know, Ryan will be just, that'll be 100% his job, right? So, you know, we'll continue to help and, you know, both in a, you know, for people who have the paid support as well as the free community, you know, IRC and mailing lists and stuff. But, you know, we wanted somebody whose sole job was to help the community. And, you know, we could use some more Ryan Big Love for our documentation. And he's already, you know, he hasn't even started and he's already, you know, he's already helping a lot with a namespacing issue. So he's already got several dozen commits under his belt, and he hasn't even started. So we're hoping for great things from him.

Well, congratulations to you and to Ryan. That definitely will be a win-win. I see that TB Dubs is also a backer and an advisor. I want to know if he has given you grief over your lack of semantic versioning. You're talking about with Jumbo? Yes. You're at Spree 07. Oh, no, he hasn't. Is that a big thing for him? Yeah, if you go to simver.org, that's the M-B-E-R.

If it's production, it should be 1.0. We are guilty of this as well. Okay, no, it will be. It will be. So the next version will be, you know, well, whatever. Within the end of the year, we're going to be at 1.0 we are guilty of this as well so okay you know it will be it will be so the next version will be you know uh well whatever within the end of the year we're gonna be at 1.0 because there's a 0.80 that's so we're working on the 1.0 now so like within by the time this broadcast airs the master branch will probably be labeled 1.0 and you know we just kind of it just cut the naming just kind of got away with us we We had 0.1 to – and we got to 0.9, and then we weren't ready, so we were like, okay, 0.10. And we wanted to reserve the right to make major changes. I guess we could have done 1.0, 2.0, 3.0. But it really took a couple years to kind of – I mean it was running production, but we were never fully satisfied.

And we're there now. you know i mean it was running production but we were never fully satisfied and and you know we're there now it was like we feel like it'll it'll keep moving forward but soon everybody will be happy with a 10 uh release you know we do the same thing this will be episode 0.6.9 and we get uh tweets at least once a week you know your version numbers aren't semantic yeah so yeah well uh you know whatever we're doing our best but um you know we didn version numbers aren't semantic. Yeah. So, yeah, well, uh, you know, whatever, we're doing our best, but, um, you know, we didn't want to signal that it was beta software, really. I mean, you know, like this is, I guess, in the Google, you know, sort of like extended beta. Um, and, but, you know, like, I do feel like we've reached this one Oh point where it's like, okay, we're going to make a little bit of disruption here where the namespace and things,

you know, break a couple more things and, know we'll get people um straightened out but but i think like rails and spree have converged a lot like there were so many things that we were doing that rails wasn't doing and you know we're in a lot more alignment with rails now like so we were just this is going back to this engine discussion you know we had our own extension system it you know it would have been fine if we had nothing and then we could have just used Rails engines. But since we had something that was almost like Rails engines, we had a lot of work to back it out. And, you know, with the I18n stuff, you know, we were using Globalize, right, Brian? Like, you know, before it really became part of Rails I18n.

And, you know, so there were a lot of things that we were doing that were kind of ahead of the curve. I mean, we weren't, you know, leading the charge. We were just kind of taking other people's great stuff. But, you know, a lot of that, we've kind of, Rails has sort of caught up to some of those great ideas. And I think we're closer in sync with what Rails is doing. I think Rails is kind of stabilizing too. So I think, you know, it's time now. Yeah.

I mean, there are probably people who aren't going to use it because it's not 1L. So we should probably fix it. So we're to the point of the show now. We're going to ask you, kind of turn it around and ask each of you what is on your open source radar and what project other than Spree that when you have a spare Saturday afternoon, what do you like to hack on? Yeah, sure. So I've been working on an extension to the face recently

that uses an external library, which is called ACE, which is the AJAX Cloud9 Editor. And it basically gives you kind of a very rich browser-based syntax highlighting editor for stuff like CSS and JavaScript and HTML and stuff like that. So yeah, it's a pretty cool project. Brian, is that going to make its way

into the theme editor for Spree eventually? That's where it's going, yeah. Yeah, so Brian also has a pretty cool theme editor for DeFace that he's working on. So, you know, other, I mean, now that I'm running the company and full bore on Spree, I don't look at as much open source as I should probably. But I think there are some projects that are on my radar um that you will probably see in a spree context soon are um well i've always been kind of interested in radiant and now more so or not more so but more recently refinery um so at rails dog they use refinery for

a non-spree project and um refinery has been very aggressive about moving it's in many ways it's a project that's similar to spree so I would keep an eye on that one. Like it's been going on for a few years. They have over a hundred contributors. You know, they're dedicated guys that are, and they're doing a lot of, they're keeping up with Rails and, you know, it's just very active.

And I think there's a big cry from the CMS community for, oh, we need better e-commerce and vice versa. So I think, you know, there's some interesting possibilities there. Um, the other thing is I'm interested in, um, uh, rails admin, one of your previous guests, a recent guest, Eric, uh, I won't pronounce his last name. Yeah. Michael's over. Um, he, uh, I think he's onto something there. I mean, there's some interesting projects. Um, I don't know that we can use rails admin for spree, but we'll probably end up borrowing

some from it. And, you know, in general, I have an interest in, um, uh, an Uber sort of admin and admin, you know, that could be pluggable. That could be really used across engines, I think. So that, that's probably the biggest barrier to integrating with Radiant or Refinery or Browser or any of these other CMSs is like, you know, anything that requires authentication or authorization is going to be a little bit of an issue until we solve this problem.

So, you know, having some kind of generic interface that you can then plug your security mechanism of your choice in and then plug in Spree and Refinery and whatever, I think that'll be cool. And I know Ryan was sort of excited about that. So that's a new open source project that we'll probably start that you can look for and that we'll want help with. And we'll probably be borrowing, you know, from Rails admin and some of the other cool stuff that people are working on. Well, the Django guys are laughing at us because they have a lot of that out of the box, but hopefully the Rails community can pick a winner in this space and we can get some nice easy to use admin.

Yeah, I'm not that familiar with Django, but I would certainly not laugh at that at any point. I think it's a great idea. I mean, I remember Yehuda Katz at RailsConf. Were you on the Vegas one, Wynn? I was, yes. You were there. I saw you there. You were there.

I saw you there. You spoke. So Yehuda gave this talk, and he was talking about Django, I think, specifically. And he was saying that we should build on the shoulders of those who come before us, no matter how small or something, some kind of reference to stature there. But yeah, a good idea is a good idea. I mean, and there's good no i'm not laughing if jango has this out of the box i think we need to oh i know i know and people would you know

deride other frameworks and things right hey there might be things that aren't good about jango but i think you know if they've and i don't know much about it but if they have got that yeah that's that's something that we we should be taking a page out of and i mean yahood made a big point of that and saying hey we need to have their elements of these communities that communities that are really good and things they're doing that we should build on. And that was something that he very much envisioned when he was talking about the Rails 3 engines a few years ago now. And WordPress and other communities like – one of our advisors is Dries Bottard, the creator of Drupal. He's an advisor to the – not to theree project, but to the Spree company. I've always been an admirer of the Drupal ecosystem.

Not all of it, and I'm not a big PHP fan, but they've got a great, huge, vibrant ecosystem that powers a big part of the internet. Same with the WordPress guys. The people who are investors are the same investors behind WordPress.

So I definitely think that we have a lot to learn from other open source projects. That's a big – the better – the more we kind of accept that, the better our stuff will be. Well, we're definitely excited about the news, the venture funding. Hopefully it will lead to some better docs and a little bit more of a community curation as staffing permits. But we look forward to the upcoming conference and keep us posted on the roadmap for SPRE. Yeah, we look forward to being enthralled by your talk. Pressure's on. No pressure.

All right. Thanks, fellas. All right. Thank you. alright thank you you