I think the entire contribution system is flawed. People pay for an improvement to the engine, which they then do not own. In fact the new features help the engine first and foremost, as they are integrated in there, invisible to the licensee.
No wonder that Hardware Instancing is sitting there for months at the same 760$. Who would ever want to pay any significant money to help the engine be more successful? I mean it's not open source that would attract donators.

I can understand that money needs to come in to survive. That's the case for all of us. But it shouldn't work like this.
However, there might be a solution.

A) The entire system could work more like the pledge system on Kickstarter. Where people pledge for various rewards, but are not charged right away, but only when the contribution finished in a fixed amount of time. The fixed amount of time is important here. A contribution should be treated like a campaign.
Rewards should not just be that the feature is implemented, but you could offer different tiers from simple donations without rewards to additional licenses when people pay 100/200 or more. And let's be honest, contributors will mostly be people who already have a license, so no danger in offering a second one.

B) If more money needs to be made, it will be rather difficult with your current licensing model I can imagine. You require a constant influx of new licenses to finance your business. Maybe it would be better for licenses to require yearly maintenance fees. Otherwise at some point you'll have thousands of licensees, but can't really monetize them.
At some point you will probably have to make a new version of the engine again to monetize your existing customers, like with the introduction of EE2. At some point you will have to cancel supporting the old version making the old licenses null and void. This would make customers even more unhappy.

I think this makes a lot of sense. I am not seeing the items I would most like to be implemented on the roadmap appearing (like Hardware Instancing) but am wary of contributing money to a fund that may never be fully funded and as such the contributors receive no direct benefit!

As customers, with a vested interest in you maintaining and further developing the engine, we appreciate your business needs to remain financially viable so I welcome an exploration and discussion of ways of making this happen and other mechanisms to help guide roadmap priority.

Sure it's his decision. Sometimes we're just missing the necessary focus or perspective.
I tried to offer solutions that could (in my opionion "would") work better.

A) how this would be done from the technical side?
I'm using PayPal everywhere, it doesn't support the option of "pledging" money for ~2 months, and then taking the money afterwards on success.
B) There will be Esenthel 3.0 in the future.

A) It's a pledge, so a promise to pay. Paypal doesn't support that. On Kickstarter they use Amazon payments for it. You enter your credit card info and it is briefly checked. (not really for the amount, though. That's the big trouble there). When the time ends, all the pledged payments are executed. Usually a percentage of those drop, around 20%. We had the same experience.

B) That's what I thought, and feared. And it's totally not what would make me as customer happy. If the license is not expensive, it's ok. But it would be great as a developer to count on your middleware to stay, so you can use it for a long time.
Anyway, the point of point B) was to offer a solution for an additional income stream.

B) It takes a lot of time for you to make and work on a new version of engine. By saying that i mean that other things on the roadmap (that other users need) are delayed. And if you are already planning to create EE 3.0 (maybe EE 4.0 in future and so on) maybe it's time to start creating it now? What's the sense of adding new features to EE 2.0 if it would be abandoned and you know that?

A. I agree with Aceio and MrPi. I know the delayed transaction doesn't work with your current set-up, Esenthel, but it's important to have the certainty that you're not just throwing away money. Of course, it still ends up with you, but not necessarily for the features that I want. I'm very reluctant to put more money in e.g. the HWI, because even contributing €200 would have no effect: It wouldn't get funded and I "lost" the money because you develop another feature (like another platform) with it, which might not be what I want.

B. I can understand both arguments. It's annoying to have to switch Editor when you're used to the old one. Of course, I can see the need for new Editors (both for income and innovation sake), but not if this absorbs too much of your time. To be honest, I wouldn't want to see a new Esenthel version (editor) every year (or two). If there's more time in between, I can deal with that.

Lastly, it's a bit unrelated, but I wouldn't even think of developing Esenthel v3 before v2 is feature-complete. I'm quite sure this is how a lot of people feel about v2 atm (especially those coming from v1). Don't take this as an insult, it's just an objective observation. While v2 is a lot more enjoyable to use, it's still lacking features compared to v1.

Regarding the pledge system, I agree it is bonkers as a feature like HW instancing that needing alot of money to pledge(and will only be for static geometry) doesn't get upped priority. I spent alot of money on that pledge, it is kinda sour seeing it sitting still at the same amount.

MrPI B) it was noted since the mention EE2.0 he would be moving to major revision license of the engine. You are free to use the old engine as long as you want, pretty much almost every engine out this day use the same approach. besides its better that a major revision of the engine will deprecate an entire system within the engine than force update it as a minor patch and after updating suddenly nothing works the same if it works at all anymore rather than having to alter name changes only.
We could argue however if an editor alone is enough to make a major revision.

Houge) Depends on what is being updated. and why not just start it now? probably because at this moment he doesn't have an end point as to getting done with it. by the same measures what is the point of developing an engine if you know at some point you will have to rewrite your renderer or something?

Developers need to see stability in middleware. At least that's one of my main filters when I check out engines and seriously plan to consider using them for a project.
If we plan to attract more developers, we need to depict that stability. Coming up with new versions and deprecating old versions is not portraying that. It wasn't my intention to discuss future engine versions. I think it's just cheap to exploit customers like Autodesk is doing (or like Adobe was before the Creative Cloud) by introducing new versions, charging for the upgrade while the software itself is insanely expensive.

I'm guessing EE2.0 is going to be around for another few years before 3.0 is even started. Considering the support in the interim, I would not be against paying for an upgrade.
You will find this situation with ANY product, where the older versions become unsupported. This idea of worrying about 3.0 screwing things up for people using 2.0 is ludicrous.

(02-12-2014 02:51 PM)MrPi Wrote:  Developers need to see stability in middleware. At least that's one of my main filters when I check out engines and seriously plan to consider using them for a project.
If we plan to attract more developers, we need to depict that stability. Coming up with new versions and deprecating old versions is not portraying that. It wasn't my intention to discuss future engine versions. I think it's just cheap to exploit customers like Autodesk is doing (or like Adobe was before the Creative Cloud) by introducing new versions, charging for the upgrade while the software itself is insanely expensive.

Can't say I agree about what classifies as a stable engine tbh. Switching out a system deprecating an old one usually means you can benefit from the rewritten code in terms of performance, memory usage.

I agree but I have a suggestion that may suit us all better

I hope to know your opinion guys

Why don't Esenthel make a vote for the most feature we would like to see first ?

Then he start working on it ! after he is done he don't release it for the licenses but he would release to whoever pay a little amount of money !
like 10$ as example or 20$

That way Esenthel profit will be good and the users will be able to get whatever features they like for a little amount of money ?

---

Paying a small fee for the feature is not very expensive for us and in the same time it'll help to improve Esenthel support and satisfy the users to get their needs

How about this approach:
-put most of the roadmap elements to the contributions section,
-assign complexity (which is estimated number of days to finish)
-calculate priority = money_raised / complexity
-I'll start working on everything sorted by highest priority like this:

Feature #1, Complexity=2, Raised=100$, Priority=100$/2=50
Feature #2, Complexity=1, Raised=30$, Priority=30$/1=30
Feature #3, Complexity=10, Raised=200$, Priority=200$/10=20

Because with this approach I'll be working on elements for less money than I want, I reserve the right to work on "element with highest priority" AND "elements of my own choice" at the same time.
So I'll be doing highest priority items, and some other elements up to my own choosing.

Additionally, very complex items, will have an extra parameter "minimum amount of raised money needed to start work".
For example, if at a moment there will be one item on the list:
Feature #1, Complexity=30, Raised=10$, Priority=10$/30=0.33
It would take me 30 days to do this, but I've gathered only 10 bucks, which is obviously not a good deal for me. So complex items, would have the extra parameter, for example:
Feature #1, Complexity=30, Raised=10$, Priority=10$/30=0.33, MinRaised=1000$
I will start working on this item, only if it has gathered 1000$ (and if at that moment it's at the top of the list).

Only very few items will have the 'MinRaised' param, which are those of very big complexity.

Let me know what you think.

Hi all,

Well, i have to say that i kinda like @Esenthel's proposal... i think it's fair enough for all... i agree that it's not so great deal to @Esenthel, to work on a task with great priority, and have to wait for to "sell" it, taking the risk that he won't do the money...

So, that propostal of him looks to me a good commitment, and it's certainly better than the previous contribution system.

@Esenthel, maybe it may seem interesting to have just another variable on the priority calculation, that is the vote weight assigned to each contribution elements, taken from a voting process open to the community. What do you think of this?

Quote:-put most of the roadmap elements to the contributions section,

What would be the criteria to choose the roadmap elements that are going to the contributions section?

Regards,

Greg, I think the proposal is much better than the current system. It would motivate people to pay smaller amounts and not feel useless in doing so.