Lombiq provides stewardship for Orchard Core Commerce

[barthamark]

Hello Community,

We'd like to announce that Lombiq Technologies provides stewardship for the Orchard Core Commerce project. Bertrand, who initially founded the Orchard 1 and Orchard Core Commerce modules, reached out to us if we are interested in actively maintaining the project. We at Lombiq are really excited about this opportunity. We want to move this forward with proper planning and frequent contributions to the repository.

On our side, I will be the project leader. A few seasoned Orchard developers are ready to implement features. But first, I want to hear your opinion about what you need first and most for the MVP. I'll put together a short survey to collect your ideas in an organized manner. Until then, feel free to comment and let us know your thoughts!

Cheers,
Márk

[giannik]

Good news.
Checkout is a must!

[Skrypt]

A modular javascript framework based checkout that works with Workflows. I think this is what's missing the most. Also, a simple implementation of Stripe or any other popular payment processor so that we have common methods from different providers to use as an abstraction for the Workflows.

Actually, the cart and checkout don't need to be javascript components. We need at least shapes that are reusable in different places in the website layout. Sometimes you can need to integrate a cart as a side panel as an example. The checkout itself could be also opened up in a pop-up iframe. Though it is more common to see a checkout as server side templates with a 4 steps wizard that post each steps to the server.

Also, I guess last one is to get a proper shipping provider for that checkout.

[mwpowellhtx]

Of course we are interested in the payments, refunds, rebates, etc, workflow. Perhaps a neighboring second to the 'checkout' nomination? Basically workflows that are simple: receive payment, send payment, I think are the bottom line. For single products, subscriptions, etc.

There are probably early contenders to consider, but we are interested in Square out of the gate, in particular. Willing to consider what that looks like, the OC workflows, potentially contributing if necessary, etc.

I did some market evaluation, OC is 'there' I think in terms of the modular CMS side of things. Commerce, of course, is much weaker. Comparing/contrasting with, say, django cms, Oscar eCommerce offerings. Just seem to be much further along in terms of 'MVP' features.

The only thing keeping me here at the moment is my affinity to dotnet, CSharp, etc. I am more familiar with that than python. Plus the python runtime constraints do not excite me about that being quite as viable. Nor does it excite me concerning the relational database modeling for the domain models and so forth. Much rather for that to be document database oriented if possible.

However, speaking in the capacity of project CTO adopting a CMS, commerce solution, etc, my preferences are more agnostic than all that. I have to decide which one is ready "now" or in what space of time, to be viable for the project in the near, medium, long range.

Still a bit of a question also, more of an OC question perhaps than a Commerce per se, but... how to feed catalog items, inventories, etc, into the system in a dynamic manner. I think that is at the time the site being rolled up and published, but if that can be more dynamic at runtime, I don't know. The latter would be compelling, but the former would be acceptable provided there is adequate comprehension to the task. In simple terms, automate, automate, automate, so that site 'authors' do not necessarily need to be man in the middle every time there is a new catalog item, change, etc, that needs to be resolved.

[mwpowellhtx]

Echo the concern, inventory management; probably somewhere along the lines of automating our products, catalog, etc.

[mwpowellhtx]

Also, extending the idea of Shopping Cart, perhaps... to things like wish lists, watch lists or what have you.

[mwpowellhtx]

For our usage, I think we will also require client/business messaging, perhaps per order, on each line item, or what have you. Maybe this can be accommodated with adequate order lifecycle workflow hooks, I do not know. Should be like almost any 'blog', messages, formatting, attachments, perhaps markdown, who knows, along these lines. These are mostly formative mud on the wall thoughts to give you an idea what we might like to accomplish.

[mwpowellhtx]

Alternatively, the demo Product Size, for instance, is somewhat compelling. If we are in a printing business, let's say, we might like to receive a list of customer images for use with the purchased product. Again, either via blog, with customer instructions, business acknowledgement, or if it is something we can add a field to, might also work.

[mwpowellhtx]

Totally agree, re: types like Amount, etc, namespaces need to be sorted out better, IMO, probably project and/or assembly organization while we are there. I have some ideas how to approach that, but the OP was not interested in that discussion at the time. Also another reason why I put this on a shelf while I considered django cms and other more ready alternatives.

[mwpowellhtx]

To his credit, does speak to the packaging... however, might also consider just stand it up in its own assembly IIRC.

[mwpowellhtx]

IIRC the original commerce in the original Orchard allowed for more pluggable parts, generic driven, let's say. I think that would be fantastic for many reasons, at least a couple of which; first, allows the commerce maintainers not to be concerned about the details of each product; second, allows adopters to potentially add compelling aspects of their respective products without necessarily worrying about the underlying scaffold.

i.e.

public class ProductPart<T> : ContentPart
{
    public string Sku { get; set; }

    public T Detail { get; set; }
}

[mwpowellhtx]

On a somewhat technical note, obviously, better styling, or at least ability for adopters to define their own, would be fantastic... it is functional here, for instance, but less than aesthetically pleasing IMO...

[Skrypt]

@mwpowellhtx The only reason why you should consider OrchardCore.Commerce is if you want something that is currently lightweight and that you want to customize for your own needs. I've been playing around with NopCommerce which probably would cover most of your needs "right now", but it is far less lightweight than using Orchard Core and also not bound to the internal tenant structure of Orchard Core. I personally prefer using Orchard Core.

So, here, the decision is more about if you want to have a separate domain that will hold your commerce or if you want to invest time in developing something that will not cover all your needs at the first iteration and that you will be able to customize over time.

OrchardCore.Commerce needs some working hands and at least now Lombiq is going to invest time on it which is a good start.

When you are talking about Square payment processor I believe that they have their own C# SDK API on Github so it should be fairly easy to implement. Though, I think that in OCC you want to have some abstractions that you can implement for common actions like a payment, monthly subscription, refund which will just need to be implemented with any payment processor out there. So, you will need to create your own Payment Processor implementation if Square is not the one that is going to be implemented by default. Having some of them as examples would not be bad either.

[mwpowellhtx]

Appreciate the response @Skrypt. Re: abstractions, I'm assuming that would be along the lines of the workflows (TBD), at the moment. But, like I said, my curiosity is piqued.

I have not looked into it too deeply yet, but I am assuming most payment processors out there have some notion of API, workflows, etc. So, what's left is to establish a more or less ubiquitous utility belt, as it were, with adequate hooks throughout.

[Skrypt]

It is always possible to abstract an external API endpoint with a local one that calls the external one ... "abstraction". In that case, this abstraction would be able to register multiple providers for payment processing which could then be used in different parts of the website or on different tenants for example.

Then you would have standardized workflows that calls this abstracted API and some custom ones for specific API calls to your different payment processor APIs if they provide more than just the common methods.

[mwpowellhtx]

Q: Will this be added to the OC meeting itinerary? Not necessarily taking time away from OC itself, maybe another weekly meeting or two. Thank you...

[barthamark]

We'll bring this up on the meeting either tomorrow or next week.

[barthamark]

Thank you, everyone, for your comments and suggestions. If you have plans to build a webshop using Orchard Core Commerce soon, please fill this short survey I linked here in this GitHub issue: #123

[barthamark]

Hello everyone. I'd like to thank you for all your patience and contribution by providing ideas and filling out the survey (you can see the result here). Let me take this opportunity and announce that Dávid (@DAud-IcI ) will take over the project leadership as I need to focus on other tasks here at Lombiq. I'll remain here as a developer and will participate in discussions where needed.