I came across this article an year ago about Spree commerce core team moving out after being acquired by a company called FirstData.
I have not seen any conversations happening w.r.t this in this forum, so wanted to initiate some discussion around it.
A quick flow of developments & state of affairs at Spree is here, which is a must-read to get a quick hang of things.
As per my understanding there are two active communities globally working on developing core Spree, which are as below.
Spark Solns and Vinsol Team in Collaboration, taking the original Spree codebase forward as mentioned here
Solidus team, which forked Spree at 2.4, and started working focusedly on various issues to make Spree more usable.
In this blogpost, which is a lil self promoting version of themselves, Solidus explains why we should fork to Solidus and start exploring all the work they are doing, and as they are also working with the same ethos of Opensource, I guess it would be fair to have a look at if any work they have done would be useful with what we are building.
I was trying to go a little deep and see some of the features and extensions these teams have been working on & I came across a few of features we have been discussing. For ex.
Tax Re-haul : As explained here, Vinsol has been trying to work on an integration with Taxjar for Spree.
Bulk Product Data Import into Spree : Vinsol has been working on a similar issue for one of their client, & its documented here
Multi Domain Store : As explained by Solidus team here, Though this doesn’t fit our exact need of whitelabelling, I think there is some work been done on using one backend connecting to multiple front-end’s.
Soliud Extensions : A list of extensions, from payment gateway(stripe), to printing invoices etc.
Backend Admin Interface : Solidus seems to have put some effort in de-cluttering the backend, documentation for same.
But Spree 3.x also seem to use Bootstrap in frontend and backend, so more food for thought.
I tried to quickly setup the solidus on heroku here (username : admin@example.com, pwd : test123) and have a look, the backend looks balanced, but as we are discussing about a single interface for both frontend & backend off late with discussions from @paroga, surely more thought reqd.
I was wondering if we could put forward our vision with these teams too, & express how we are heavily investing in Spree as our Future choice, & discuss how we could collaborate with them w.r.t building these features/customizations, so that there are not multiple efforts/funds spent to build these features on Spree.
And this also might be a step forward in helping us contribute to the Spree Global Commons.
p.s : Both of these teams have slack channels too with some active discussions happening too, so random discussions w.r.t Spree & OFN can be put up there too.
most excellent work @sreeharsha!! This is incredibly useful and seems like an important discussion / decision that we need to make in relation to spree upgrade. I think we can still safely progress the work as we’re not even upgraded to v2.0 yet, and the decision doesn’t need to be made until we get to 2.4 which is where Solidus forked. I suspect we’ll be in a better position to make the decision once we can see how things look at v2.4
It does seem like looking at what is being done should inform strategy around tax, embedded / standalone shops and possibly some of the inventory management. I note also that they’ve gone to the vertical admin control panel in solidus @oeoeaio
And they have a stock management feature!!! With the possibility to transfer stock
I’m not sure about the tax overhaul impact as from what I have read, they still are based on kind of “fixed tax categories” that are supposed to be the same from state to state (they seem to work mainly in the US…) so there are improvements but our case of “the bread is taxed in France and not in Spain” doesn’t seem handled, neither the capacity to display tax in shopfront or not. Hum wait…they seem to say here that they handle “product-level taxability”… well definitely we should investigate more, that is a super clue @sreeharsha, it could save us so much time!
It seems we can’t see the taxjar integration in your deployment @sreeharsha, right?
@MyriamBoure , The deployment link is of the codebase of Solidus. But the taxjar integration mentioned here, was done by Vinsol, who are part of core team of the original Spree Product codebase. (Recollect I said we have two major Spree Active communities).
I think many more of us who have deep knowledge on our requirements & our productbase, have to look through what developments they have already done, in process or in their pipeline, and figure out if we could collaborate.
I tried to get in touch with Priyank from Vinsol who is based out of India, who is mentioned here, as one of the core contributors of Spree latest core team. I am yet to get a reply, will wait and touch base again.
I was browsing through extensions of Vinsol & came across this subscription extension, and was wondering if we could derive some use for our Standing Orders usecase. It looks an end to end implementation but more from a single product point of view. More detailed description here
I came across this google group of Spree users, which has a more diverse group of users and developers from core SPree team. Just for reference.
Thanks @sreeharsha! Looks interesting, there are a lot of parallels with the way I have implemented standing orders, but obviously our implementation has to work with Order Cycles. Sadly, I think we’ve come too far along the path we’ve already travelled to go back and try and integrate it (particularly as it depends on Spree 3.2 / Rails 5), at this stage.
hello all. glad to see someone brought this up as i was going to ask about the upgrade path. i’ve been through this, but i jumped on spree later than you guys, at 2.1, although i probably had a less customized base than you. there was a lot of disruption along the way in terms of api and functionality, and also some big security issues (eg, the ransack queries). i went through each iteration upgrade, and finally to solidus 1.x, then to solidus 2. it was pretty painful. at the end of it, i regretted customizing spree classes, and started moving customization out of core spree models. another rails pain moment of teaching good software engineering by negative examples (loosely coupled, highly cohesive)
during that time i worked for a company that was a client of resolve digital, and that team is great. i’ve had a few interactions with the solidus team on github, and while i think they are doing a good job, there is a lot of code cruft built up in spree and some lack of leadership in terms of design decisions (this was a problem in spree as well). but this happens on any mature OSS project.
i too was excited about the stock management feature. i was also working on a supply network type of application. par the course, there isn’t a lot of documentation, but the models are pretty explanatory and as usual the most reliable docs are the specs.
another thing about solidus is they haven’t made your life too horrible by changing Spree:: to Solidus:: yet, so much of your customization can be ported over quickly. how long that will last, i am not sure, but most of the models have the same names and are in the same class hierarchy.
i am currently researching software for our food buying coop. i was pretty excited to find OFN, but it seems like there is a lot missing for buying clubs. i need to figure out what direction i am going to take, but since the food coop is primarily volunteer work, i need to be pragmatic about what solution to use. one appealing part of OFN would be if i can contribute and OFN will host it. i want to ensure that my food coop can rely on whatever the use whether or not i am involved with it. if i do go with OFN perhaps i can try and migrate your 2.x branch directly to solidus 2.x.
so glad you are jumping into this discussion @carchrae - and great to see another Canadian pursuing OFN (especially nice to see a technically-inclined Canadian. My time has been spent getting some food hubs on the platform as users and haven’t turned attention to bulding a technical community here yet.) .
RE: buying clubs - I actually am running a couple of buying clubs on OFN now and I have found the existing features in OFN OK (better than what I was doing before). I know that @enricostn and his team have been also looking into OFN and buying club features too - I think also recognizing more could happen here.
Re your decision about what platform to use - I can say that the community around OFN internationally and in Canada is growing fast - so if others take over from whatever you set up for your coop, there will be a community of users and a structure (not-for-profit organization) in Canada to help them. Canada will continue hosting at least one instance of OFN - that is quite stable financially and organizationally.
it may be worth mentioning that some of the core solidus team are based in canada too (https://stembolt.com/), not far from me in victoria, bc. this may be useful knowledge if you need to find developers using canadian govt funding.
i installed foodsoft and i think it is probably a better fit for our buying club. i had been drawn to OFN because of my own experience with spree, however, it looks like it could be quite a lot of work to make OFN fit properly for a buying club. i also have several scars from where i tried to make spree do things that were far removed from simple e-commerce transactions.
also, i think it is probably a good idea to get your upgrades complete before adding any further customisation to spree.
i don’t know if this is helpful, but my eventual approach to customising spree was to do most of the custom stuff via the spree REST API in an independent application. this gives a lot more freedom and makes upgrade paths much easier. yes, you can customise all the spree classes, but it becomes very brittle when upgrading. another advantage of the REST API approach is that you can expose parts of spree to different systems. their documented REST API was one of the original draws for me to spree, however, the implementation of it had a lot of functionality holes in early spree.
hi @carchrae - it would be great if you want to continue in these conversations even if you choose to go with foodsoft for your buying group, both with a view to potential linking via api (Connecting food cooperatives) and helping shape any changes / improvements to OFN for buying groups
also, are you on Slack? and if so are you on the channel #workopportunities? please let me know if you are potentially interested in working on the spree upgrade as a freelancer. We are lining up resources to do this at the moment and looking for the right people to be involved. Sounds like you might be a good fit . .
hi @Kirsten - happy to continue to contribute thoughts or more. happy to come chat on slack sometime. can you send me an invite tom@intellecti.ca
i think it is likely we will go with foodsoft because it will take less time to get it working and our food co-op needs it asap. i’ve deployed an instance of foodsoft on heroku, but haven’t done much more work on it yet, but it seems like a good fit. i would like to test how it scales up when there are more products/etc. i see that foodsoft is also working on an API, but i haven’t looked at this yet https://github.com/foodcoops/foodsoft/pull/429
re working on a project, perhaps. although i spent a few years at it, i don’t enjoy spree work - however, i do strongly support the general mandate of OFN in promoting a better connection between us and our food producers.
is there a public tech roadmap for what OFN want to do? for an upgrade, i would suggest doing a time-limited spike to get as much working as possible in a small window, then review what is broken and how critical those features are.
Re. spree upgrade, there are a couple of pages that outline proposed approach. It would be great if you could make a note / add advice on those pages so we can be sure it won’t get missed by the devs that pick it up?
Now that we are saying “bye bye spree”, i.e., we have decided to move the spree code we need to OFN and remove the dependency. This post becomes outdated.
