EntityFramework-Reverse-POCO-Code-First-Generator
EntityFramework-Reverse-POCO-Code-First-Generator copied to clipboard
Clarity on licensing
Hi Simon
Just seeking a clarification on your licensing. My case is for a specific project that I will be working on for about 6 months. I am happy enough to buy a license, because I value what your product does. What happens for my maintenance task though. I will probably have to touch this project every now and then in the coming years - will I need to keep buying licenses - or can I just continue to use the version that was active when I was licensed?
I am assuming you can see the issue here if every time I come back to a single project (which is currently the only EF one I work on) just to do a basic maintenance - we are talking probably running a script a single time every year or so - then I need to get a new license?
Hi @statler
I see your problem. Yes you will need an active license each time you want to run the generator. I've kept the cost low, and just a single reverse engineering run will save you the money it cost in terms of development time alone. The alternative was to charge like red-gate and others do, a single £250 fee for the life of the product, which is only about 2-3 years before the 'next' version comes out.
I could offer a longer (say 3 and 5 years) licenses at a discounted price...
Maybe consider something similar to what devexpress does? With a purchase price and then ongoing license costs if you need the new features, but you maintain the rights to use an old version from when you purchased?
On Tue, 10 Dec. 2019, 9:19 pm Simon Hughes, [email protected] wrote:
Hi @statler https://github.com/statler
I see your problem. Yes you will need an active license each time you want to run the generator. I've kept the cost low, and just a single reverse engineering run will save you the money it cost in terms of development time alone. The alternative was to charge like red-gate and others do, a single £250 fee for the life of the product, which is only about 2-3 years before the 'next' version comes out.
I could offer a longer (say 3 and 5 years) licenses at a discounted price...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sjh37/EntityFramework-Reverse-POCO-Code-First-Generator/issues/556?email_source=notifications&email_token=AACSQR3IO65A467LNWLLPCTQX5UJ7A5CNFSM4JYUVOQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGOW5YA#issuecomment-563965664, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACSQR3PBRNUYDTSPNLBTCDQX5UJ7ANCNFSM4JYUVOQQ .
I have a similar use case as you. We have dozens of small internal apps and multiple developers, some of which like to use EDMX or some Visual Studio Extension to generate the models (I personally like this generator compared to the other methods). If i'm working on a new project and another developer needs to make some small update like adding an extra column for a flag, what can they do? Or later on it gets passed to someone else to make a small update (not uncommon at our place).
A license per developer per year and the need to install the license file per machine makes it much more troublesome for these kind of quick one-off updates for other developers.
I can't even justify to my boss to purchase this because of the portability and usability issues present unless I was the sole developer or somehow convince my whole team to use it.
The good thing about the previous version was that everything was self-contained in the project. Anyone could open the project, save the TT file and have it work.
I wouldn't even mind a higher purchase price for a one-time license that can be included in the project itself so it's self-contained. And to be honest, I can't imagine needing to get an updated version of this that often and if I did, would just purchase the update when I need it.
@0xced @TimSirmovics @agentknipe @vipasane @mikaelliljedahl @baoshenyi @kinetiq @0xced @sanddigital @Jehoel @rcheung9 @staff0rd @statler
Hi Chaps, I value your opinions and I'd like your thoughts on additional pricing models for the generator.
Perhaps there is a need for a solution license? A license file that lives with the .sln
, so any developer can save the projects .tt file.
If so, this gives rise to the following table:
Name | Developers | Projects | Years | Price |
---|---|---|---|---|
Per Developer | 1 | unlimited | 1 | 79 |
Per Developer | 1 | unlimited | 5 | 249? |
Per Solution | unlimited | 1 | 1 | 25? |
Per Solution | unlimited | 1 | 5 | 99? |
Ultimate | unlimited | unlimited | 1 | 249? |
Ultimate | unlimited | unlimited | 5 | 999? |
Any updates to the table above? What prices for the question marks?
It's really important to get this right. Thanks for your help.
@sjh37 Hey Simon.
If the idea is that you license each solution once and then an unlimited number of devs can generate code, it seems like the price should probably be more than the Per Developer price, not less. That also sounds like it could be a tedious / complex model.
However, if Ultimate unlocks unlimited devs and projects, why not just let that be the solution? You would be deciding that you want to make $79/year on independent developers, and $249/year on larger organizations.
If there are only 3 devs they would buy 3 dev licenses. If more, Ultimate.
I would definitely consider making that annual pricing with a reduced renewal rate / early renewal rates / etc. Seems like you already thought of that. :)
First up, thank you for listening and engaging on this. It is really refreshing. As I said earlier, I am happy to pay for the product (actually I already have), but think these tweaks and discussions are necessary.
I feel that what is missing is the option to buy once incl. 1 year updates, but right to continue using after without updates. This would be more important to me than the long term options. The reason being that if you have a project that hangs around for years but is rarely touched - and can be touched by numerous different devs, you don't have to keep paying for the version in it when you effectively aren't using any new features, and rarely using the features you have already paid for. I don't think this offer would be necessary for the ultimate subscription if you already have the solution option covered. Optionally you could limit this to the 'per solution' option, but I think there would be many who would like it in the dev license option too - I would just use the solution option because then I can clearly cost it per project.
If there aren't any updates that users feel they need to pay for - then what are they paying for each year? A subscription model is based upon the provision of resources and features evolving to increase productivity. I understand the work associated with product maintenance, but if this maintenance is necessary for an end user, then they will pay for it.
The way I deal with it in my software licensing is that purchasers who later want an updated version outside their maintenance period have to purchase again. That makes it a value decision on the part of the end user. E.g. if I have a solution that I purchased the license for, and 3 years later I need to get an update because .Net Core changed and my version of revPoco no longer works, then I have to either start a subscription or re-purchase. That is fair to everyone.
Name | Developers | Projects | Years updated | Price |
---|---|---|---|---|
Per Developer (subscription) | 1 | unlimited | 1 | 79 |
Per Developer (purchase) - maybe don't need this | 1 | unlimited | 1 | 149? |
Per Solution (subscription) | unlimited | 1 | 1 | 25? |
Per Solution (purchase) - def. need this. | unlimited | 1 | 1 | 49? |
Ultimate (subscription) | unlimited | unlimited | 1 | 249? |
@statler Yeah that's right, what I usually see is an initial price for a year, and you get free updates during that time.
If you renew, you get it for cheaper than the initial price. If you lapse, you stop getting updates and can continue at that initial price. During the lapse period you probably have a funnel that hammers them with a last chance to renew offer from time to time, or for a week, etc.
I think companies like to also do early renewal pricing because it provides a way to engage with people more, create some urgency around renewal, and it's probably also a cash flow thing.
@kinetiq
Can't agree on the comments for per-solution licensing. Consider a company with 5 devs with 1 project that uses the library. The project is maintenance only.
Or alternatively 1 dev with 1 project
Personally, the per project options are the key.
That's how most of the software tools / libraries I buy works. You buy it and get 1 year of updates if you don't purchase a support plan, after that you can keep using that version until you feed the need for new features.
Seems weird and fiddly. I've never licensed anything on a per solution basis.
But I have no dog in this fight - I'm probably missing something.
For my organization, we have 6 developers, but support near 100 applications, for us the option to buy for all of our developers and all of our projects is ideal. While not all of our project are using the generator at this point, as we move forward with Core updates, more and more projects will be using it.
I happen the think the price point per developer is fair as is, but understand that a per application pricing model could be useful for some. On the one purchase that works for a specific version or version, it brings up questions about how updates happen. If I need to bring this up in git hub, let me know. If a new version comes out, are the templates updated or do you need to add a new reverse poco object, copy your settings and then drop your old t4 files. Is there a way to keep the generator at a specific version and not upgrade?
If a new version comes out, are the templates updated or do you need to add a new reverse poco object, copy your settings and then drop your old t4 files. Is there a way to keep the generator at a specific version and not upgrade?
Good question. This is not a product style application where you can keep it at a certain version. If I push out an update, VisualStudio notifies you and then updates the generator template. You always get the latest version regardless of the major number. The generator files in your project will remain as-is unless you update them manually of course. I don't want to tie the generator license to a specific version because my thoughts for the generator was to leave it at version 3 for as long as EF Core has not been superseded. Which I personally think it will be at least 10 years before that happens.
Licensing is all down to perspective:
- Single developer.
- Small team, lost of projects.
- Large team, few projects.
- Large team, lots of projects.
- Projects in maintenance mode
I'll keep thinking about it. I'd like a decent, honest solution most people will be happy with.
I have been using the old version for EF 6 and I have not needed to upgrade the version of the T4-template for 2 years. It still works excellent with EF 6.4 in .Net Core 3.1. We use few custom options, one of them is the custom pluralization names. We use it for 2 databases (2 T4-files in one project file) on 2 backend developers.
I look forward to migrate this to using EF Core 3.1 one day. But in a startup the recurring fees are always a bit discouraging.
Probably we will just go for the per solution payment and pay for 10 years in advance, if that would be possible ;)
This is a good product and the developer deserves to be paid for his work but one of the other problems I have with a subscription model instead of a higher priced perpetual license locked at a specific version (which I hear is hard to do with VS Extensions... but can't you make a new extension and call it EF Reverse Poco 2025 or something) is the longevity of the developer. I assume this is a side project for him and not his main job... What happens in 10 years if he abandons the project due to personal reasons or gets "hit by a bus"?
With the .NET Framework projects using this tool, I have peace of mind that 10, 20, 30 years later I (or someone else if I leave / retire) can still open the project and work on it... well there will be probably be new tools and platforms by then. In the grand scheme of things, I or someone else will probably figure it out to purchase a license if still available or use some other model generating tool, but preferably would rather not tie source code to a license.
@sjh37 Honestly, this particular subscription model steers me away from using this tool. I am not against paying a fair price for a good product, but I am not willing to tie multiple projects in maintenance to a recurring fee.
It should be possible to buy the latest version once with 1 year of free updates and then optionally pay for the next major version. Just like most software companies already do. My company is already paying for a lot of products that have this licensing model because it is safe - if something unexpected happens, we can continue using the product we paid for, otherwise we have to plan for a migration to another tool.
I agree with @rcheung9, this is not a viable and fair long-term solution. Even Resharper includes a perpetual fallback license, in case you stop paying for the subscription and that isn't software that would stop the project in its tracks, because it's just a client side tool to aid development. Reverse POCO generator would bring a project to a complete stop in case we stopped paying for it.
I don't mean to be rude, but this model is just greedy.
Hi @janissimsons Fully understand. This is not a standalone product but a Visual Studio extension, and updates to the latest version will always occur via Visual Studio. So it's not as straight forward as it first seems. One answer as @rcheung9 pointed out is to create a new extension for a new version, rather than extend the current one. When a project goes into maintenance, the database is usually stable at that time, and the EF code has already been generated. You do not need the generator to change some code and push out a change. The generator is there to save time and prevent mistakes. If there were changes to the database that needed to be brought it, you could always do it by hand if they were small enough. As long as the time spent was less than the cost of a license (usually 2 to 3 hours), you win. I'm leaving this case open as I'm thinking how best to solve it, given that its an extension that will always be kept up to date.
Created case #588 to offer per solution licensing.
Well, I bought two licenses yesterday. If I had more devs I would buy more, just like with Resharper, red-gate, etc.