Offsite Payments Maintenance

[mnoack]

Hi, it seems there are a lot of PR's in this project (mine included).

I have a thought on how to improve the community and handle them.

Given most PR's are adding/updating gateways (not core code), and most users only use 1-3 gateways it makes sense to make each gateway a gem, big ones that activemerchant/Shopify wish to maintain can be hosted/maintained by activemerchant, and niece ones can be maintained by people who are using them live (e.g. we use MiGS and POLiPay)

This way:

• as soon as 1 person uses it live and publishes it, it's easily available to everyone
• each can included dependencies it needs (no need for big gems in core of offsite_payments)
• gems can test via travis against various version of offsite_payments core gem to ensure they remain compatible, so offsite_payments will need to be semantically versioned

Thoughts?

[mnoack]

And so people can find these integrations, anyone that makes a gem could simply contact activemerchant to have a link to their gem on offsite_payment's readme listed (with offsite_payment's disclaimer)

[aprofeit]

Hey @mnoack, thanks for the suggestion.

We've been discussing ways to keep this project better maintained and this is an interesting idea.

I have a few worries though:

• Maintaining consistency in the gems. Once the integrations live outside AM it will be harder to ensure they all continue to behave the same.
• It's possible someone adds a feature to their gem gateway that AM doesn't want. That would mean AM would be stuck at an older version and be unable to upgrade any further.
• Depending on the number of dependencies the gems had, could end up with conflicts between different gateway gems.
• What happens if someone contributes a gateway via gem and then abandons the project? Do we fork it? Copy the code back in to AM?
• It's great that you would be willing to take ownership of a couple gems, but I'm unsure how many other people would. I'm worried we'd end up in a situation where MiGS and POLiPay are the only gateways included via gems.

While this would solve some problems, it introduces others and I'm not sure it's the direction we want to go, at least not now. Definitely appreciate the suggestion though, has spurred some more discussion on how we can keep the project better maintained.

[mnoack]

Technically I'm doing this process now, MiGS has been in PR for over a month so we're using our fork in a live situation.

What AM could do is maintain gateways in separate gems, but could treat gateways with 3 status's 'official', 'supported' and 'unsupported'

'Official' are ones AM's own team maintains, these would be the big and important ones, like PayPal

'supported' would be ones where AM's core team are given commit access to the repo/rubygems, which would resolve most of the problems you pointed out, because for these gems the situation is the same as now, when a change to AM is done, you have access to all the projects and can update them to keep them in sync. To be official someone from AM also has to review your project to ensure gems are fine, etc. (addressing your other point).

'unsupported' is currently where MiGS/POLi are current at, where someone like myself has maintained a gateway but hasn't yet got support, it's a great first step for gateways to be tried/used until they meed AM standards to become 'supported'

[lulalala]

I maintains a gateway gem for my company. It's a gem because I know Shopify won't have the resource to review or maintain it. It worked quite well.

Maintaining consistency in the gems can easily be solved if Shopify's can provide a implementation guideline. For example, the semantic of common fields (e.g. return_url in form helper need to be defined. This way implementors knows how to implement the form helper which can be compatible with each other.

someone adds a feature to their gem gateway that AM doesn't want. That would mean AM would be stuck at an older version and be unable to upgrade any further.

Along the lines of @mnoack 's suggestion, I think you only need to be responsible for the official gateways. Other implementations should be following the core, instead of the core stucked with them.

I'm worried we'd end up in a situation where MiGS and POLiPay are the only gateways included via gems.

Since I am already doing this, I feel Shopify don't even need to worry about it.