Im interested in providing part of magento ecommerce as a SAAS solution. However, it would be great to get some clarity around the osl license.
I realise that distributing that actual software requires me to open the source. However, in a SAAS environment, surely I can charge for the software service? As long as I release all changes to the core code etc?
How about using the XML API to provide data - I guess thats ok too?
What about if I decide to let the user have the source code? what would I be obliged to do then? let them have it? release all changes?
Anyone have any experience with this? ps I realise you may not be a lawyer ;]
Cheers
Ke
What I would do is charge the user for the hosting. You can sell your customizations as you please as they technically are not subject to the Magento license.
I would stay away from making changes to the "core" code and instead build off of them. That way you are not selling modified versions of the core software (which would kill your ability to easily upgrade the system).
You are allowed to license your extensions however you please so you would not have to worry about the open source model.
Related
I have to say I am fairly new to CI/CD and how to automatically update softwares.
I am developping a monitoring software for industrial customers. We have come to the point where we need to think about an updating strategy to make it easier to deploy our newest version to customers. However, my knowledge on the matter is quite poor and I don't really know where to start.
Our main idea is to have some sort of launcher where, on startup, the software detects that a new version is available and asks the customer if he wants to download it. The problem is that I don't know where to start to put in place that strategy.
Prior to my researches, I had come accross kubernetes, docker, Jenkins, and GitLab but can't figure out if they do actually what I want. Furthermore, I have looked at Microsoft's Configuration Manager but it seemslike you can only update softs that are on your network.
Feel free to ask for any info.
Thank you in advance for your help ! :)
We are setting up a new e-commerce site and while trying to figure out which platform to go with, I would like to know, is there way to migrate from MagentoGo to the Enterprise edition?
Cheers,
Iraklis
p.s. In case you want to contribute to our platform quest, feel free to write your thoughts on this post,
Both editions should have support. I would ask Magento what options you have.
Having said that, you can probably migrate most of the product information using the API and/or DataFlow. That will require you to write a script that takes the information out of Go and then put it into Enterprise Edition.
Orders will probably be a more complicated beast. There is an API available for orders so you will probably need to use that. However, migrating payment information may be tricky as you will likely charge the customer again. I would probably change the payment method to Purchase Order and put the PO value as "Migrated Order".
However, the first thing I would do is talk to Magento about what kind of options you have. I have to imagine that they have created a method for people to migrate out of Go and into Enterprise. They should be based some somewhat the same code so maybe the database can be moved over as well.
I am trying to find the best way to maintain a bug tracker and feature/upgrade requests for clients on web development projects. Ideally it would be an open source system we can have installed on a sub domain of our site.
This will then allow each client to login and add bugs/features/upgrade which we can hopefully keep track of.
I have been trying to use and implement trac but it just feels too "techy" and a little too complex for setup.
Any ideas?
Thanks in advance,
Shadi
UPDATE
Just to clarify, we do want a system to install on our servers, the trouble with trac is the install process in relation to what you get and how clients feel about it is a little poor. But if something is awesome but has a complex setup, that isn't a problem...
Mantis is another. Simple UI.
http://www.mantisbt.org/
If you have Linux boxes, trac is much easier to install. Config takes a bit, but wasn't a problem in my experience.
I've heard good things about FogBugz. :)
If you don't want to install it yourself they have a hosted solution also.
Have you taken a look a Bugzilla? Not sure if it meets all your needs but it is free but you can get paid support. It's an open source project AFAIK.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have some concerns about the Integration of Magento with other CRM,ERP systems.
How is it possible to integrate Magento with any other Industry standard CRM and ERP system?
How can i fetch the data from a ERP and update Magento database, like transactiona replication. Is this possible? And Whats the right way to do it?
Also, How can i integrate Magento with POS? Is it possible to have bi-directional data update between Magento and Industry Standard POS?
I hope I have stated all my doubts and made it clear. I would be thankful if someone guides me to do the integration, the Right way.
If you're using Magento Enterprise Edition, take a look at Bridge Connect, which is a service specifically built to integrate with common ERP packages. If you aren't using EE, or if you don't want to pay for Bridge Connect, your best bet is to use the webservices that Magento provides for this task.
The big advantage of using these is that they are relatively stable between upgrades, so you won't completely break your upgrade path. The downside is that they are slow. Silly slow. And they leak memory like a boat made of toilet paper. In my experience, though, this is nothing compared to the trouble of upgrading handwritten code when Magento decides to change the underlying database.
As for a POS, in simple cases the Magento admin sales interface may suffice. You can take CC payments, arrange shipments, etc, and your orders will be approximately the same as if they had been submitted from the web. If not, you're back to webservices if you want them in the Magento system.
If your ERP system is handling fulfillment, you may be able to skip the step of adding POS orders to Magento. Let the ERP system be the system of record for inventory, and just update Magento w/ the new accurate inventory quantities periodically.
Hope that helps.
Thanks,
Joe
EDIT:
Magento has not stated any plans to change the database that I am aware of, but it has happened several times in the past without warning, and it would be risky to assume that nothing will change. Varien does not make any guarantees about the database format, or whether it will be changed significantly.
When such a change happens, the APIs and objects in the platform are adjusted accordingly, so keeping it above the database level will keep you insulated from those changes, and make the job of evaluating new releases for compatibility that much easier.
The Magento orders/sales database structure was changed in latest release from EAV to flat structure (huge performance boost) and I don't foresee much changes in the near future, however it is highly discouraged to play with DB at the lowest level - try to integrate on Models level.
As for ERP integrations - there are couple options - BridgeConnect offers part of the functionality, webservices too (but there is no order creation in Magento via webservice for example) and you will need middleware or call API from 3rd party system. If you need speed, your best bet is to write a custom integration piece as a Magento extension. If you need flexibility and quick solution - use Webservice (you can extend them too with extensions).
As stated in your accepted answer your best bet is to use the API (either web service or XMLRPC). I used the API to build interfaces into and out of our ERP system using Mule ESB as the event/transfer layer.
If you can't find an API method you need and/or the methods don't work out for you, you can extend the API very easily.
Unfortunately, it looks like as August 2010 Magento does not support BridgeConnect any longer. There are some third party vendors who seem to filling the void for at least a couple ERM solutions.
Unfortunately, after much searching, I still haven't been able to find an integration solution for NetSuite.
Yes, API and XMLRPC/Web Services is the way to go. Another option is to look for pre-existing Magento Extensions that already do what you are looking for. The Bridge Connet is certainly an option and we considered it for our customers, however we ended up developing our own Magento POS Extension for RunIt POS.
The Magento Extension is now for sale on our website at https://www.activo.com/runway-magento-integration-with-runit-pos/ Check this link if you need more info, we also included an overview video and we have setup a demo for you to try if needed.
This is definitely a growing need as I see more and more web stores need to integrate with back end services due to the growing demand of online commerce. We will be rolling out new features and other extensions that enable online merchants do more with their existing Magento stores.
I think you should take a look on Quick Books POS integration with Magento also see ecc extension for sync srevice btw both systems.
The team I'm working with have created a CRM4 add-on which encapsulates 'standard' CRM customisations (such as modifying existing entities, adding our own custom entities), reports, plug-ins, and our own web pages (in IFrames) and web services. All pretty typical stuff.
I'm writing all the requisite installation code to simplify / automate the install process so that our ISV add-on can downloaded and trialled by anyone, but have been asked to think of appropriate way restrict functionality - to encourage people to purchase a license.
I'm not that familiar with the concepts/best practices/pitfalls when it comes to the 'licensing' of .net apps (especially CRM4 add-ons) so am asking you if you have any suggestions. We're looking for something fairly simple, and should be reasonably 'crackable', since we believe that having to enter a license code is generally a PITA.
Does the CRM API have anything to offer the ISV developer? (I see that one is able to nterrogate the License entity, but I'm assuming that this is for the CRM license itself)
Are there any existing code samples / projects / frameworks that are appropriate to use or implement?
I'm tempted to create a Registry Key upon installation of the add-on which, if after a month the correct license key has not been entered, will restrict functionality. Is this the best way to do this? Have you seen any other add-ons do it differently / better?
In terms of restricting functionality, I'm thinking of throwing InvalidPluginExecutionExceptions. Surely there must be a more 'graceful' way to do this?
All thoughts and suggestions appreciated.
Regards,
Peter.
My thoughts:
Yes, you can query the License entity to get the number of licensed users, which is a common license type from what I've seen. Lots of 3rd party vendors charge by the number of licensed users, regardless of how many of those users actually use the customization. I try to stay away from these because the license costs are often prohibitive for enterprise deployments.
Not that I know of.
I like this option, and have seen at least one 3rd party tool use this method. They allow you to declare the license key in your .config file, and if their runtime doesn't find it there it checks a known registry key. The tool comes with an app that registers the license key in the registry for you. I'd be careful to test and make sure your custom code can read the registry in a least-privilege environment.
Definitely not graceful to throw exceptions, but it does prove your point. :) Other than that, just outright skipping your code is another possibility, although that could have data implications. If you must throw exceptions, I would suggest trying to run some javascript on form load of your entities that warns the user that their license is expired and a save will result in an error. Some more nefarious schemes could include Thread.Sleep, kinda like the old shareware nagscreens. :)
Another idea - can you set up an Enterprise IFD deployment so you can give customers remote access to your demo, including their own demo organization? This depends on your audience, but your customers may not have the luxury (time, dev environment) of downloading and installing your trial. They may just want to see it in action - once you qualify the sale maybe you offer free remote installation and not spend so much time on a flawless setup package? Again, depends on your audience and the volume of licenses you expect to sell. Technically, you could dynamically provision organizations using the SDK and make the online trial process completely automatic. Of course this is a big investment, but allows you to maintain absolute control over your demo/IP.
Hope that helps!