blog/seamless-crash-protection/

[giscus[bot]]

blog/seamless-crash-protection/

The new com.codename1.crash client captures crashes on device, scrubs personal data before anything is sent, retries reliably through a storage-first queue, and lets the build cloud symbolicate native crashes and file them as GitHub issues instead of emails.

https://www.codenameone.com/blog/seamless-crash-protection/

[ThomasH99]

Great step forward with these crash improvements, and it solves several things I had done on my own. However, since it is based on your Cloud, it is correctly understood that it is only useful for paying CN1 subscribers?

[shai-almog]

Thanks. Yes, it's always been a pro feature. We plan to introduce more cloud features in the coming months to make Codename One more sustainable as a business while keeping it competitive, free and open source.

I wrote about this years ago OSS is difficult as a source of income. The solution some companies take is to pivot to a "not exactly OSS" model that effectively guts/splits the community. I think the best model is a clean split: what's free for us is free. The stuff that costs (servers etc.) isn't. That's both fair and sustainable assuming we can get the community to grow and a reasonable amount of developers to convert to subscribers. It's also a big advantage over some competitors who are stuck in a limited box because of their corporate overlords.

Specifically symbolization of the binaries is a non-trivial complex process that requires producing, moving around, storing and tracking large symbol tables for every build. That's why it's only a paid service.

[ThomasH99]

I fully support the idea of making a business viable and getting paid for all the hard work. But maybe you’d get better traction with a more graduated model where paid features are available for free at low volume and your users only need to pay when their app actually takes off (and volumne increases). The payment could also be automatic not to block users during early ramp-up, eg you enter a credit card and a max charge limit and you’re only getting charged when relevant. Anyway, just an idea based on my own problem with paying a not-insignificant monthly subscription before my app is released and/or making money.

[shai-almog]

I agree with that notion 100% and indeed we do just that when it fits. E.g. the free cloud build quota is one of the perfect examples of this policy. We do plan to include additional features like that in the basic/free tier. We consider this carefully for every new feature we introduce e.g. analytics that we just introduced is limited to basic tier.

The logic is that this can produce a large volume of traffic. Retaining noise from an army of free accounts won't be financially sustainable. Crash protection is even more important. Hundreds of gigabytes of symbol information won't be sustainable in the current pricing model.

Next week we aim to introduce support for payment services which will be tiered all the way down to the free accounts. The logic there is volume so we can afford the smaller overhead of the free tiers and do exactly that.