Somewhat similar to thesequestions, I am struggling to estimate how pricing would work out for my organization in practice. We develop many small embedded systems (primarily motor controllers), which are often derivatives / forks of older projects. Once a project reaches production we rarely have to do any continued development (no connectivity to Internet, no dependence on external software, etc.) and, in fact, sometimes are prohibited from doing so by the end customer (could invalidate qualification / certification).
Based on my (albeit little) experience with SonarCloud so far, it looks like we would have to delete old/inactive projects and lose all of their history. However, if it were possible to do something more like “archive” them so we could still reference historical information without counting toward our LoC limit then we would much prefer that. Is there recommended way to handle this situation? I see 3 potential options:
Pay for a much higher LoC subscription than is otherwise needed – downside is obviously that it costs more, potentially a prohibitively high amount
Delete inactive project – downside is loss of history and would need to “start over” in the event that an unanticipated field update were required.
Disable analysis of code on inactive projects by excluding all files from analysis – downside is that it feels like a “hack” and I do not yet know if it would even work.
As a side-note, if you could offer pricing based on team size (e.g., 5 developers / committers) that would make it likely easier for me to pitch this product to my managers.
Our pricing model is based on the value you get from the product. More lines of code under analysis → more value → a larger license.
Uhm… have you checked the plans and pricing page? 500k lines of code is €160 / mo. 1 million is €265 / mo.
Yes, you could exclude all or most of the code in a project and reanalyze to bring its “active” LOC down and decrease your license code. Yes, it would work, and yes, it’s a hack.
One thing I think you’re overlooking here is the fact that SonarCloud analysis continually gets smarter and continually finds new, “harder” issues. Next month, 6months from now, next year we’ll be detecting things we can’t today. Even if these projects are dormant, it may be worth your while (and your clients’!) to periodically re-analyze and make sure nothing new shows up.
Uhm… have you checked [the plans and pricing page](Plans & Pricing? …
Yes, and I think for the amounts we will need they are reasonable. However, our project structure is a bit weird / not currently following best practices in a way that could make costs much higher than would be proportional to value (we are a small team with a limited budget). I just did a quick check and see 130 firmware source code repositories weighing-in around 10k LoC each, but about 80% of that is duplicate (e.g., library code from vendor and “standard” in-house actuator control framework reused by copy-paste/fork) and only about 10 have had commits in the last year – some are purely historical (e.g., prototypes for projects that didn’t get off the ground & code for discontinued products). We may try to improve the organization of these projects (e.g., modularize reusable portions of our code into separate repositories/project and link), which would solve the main issue (billable LoC can become far higher than actual project complexity), but this will take some time and effort. In the meantime we will probably end up sizing the subscription based on how many active projects we expect to have over the course of a year and then archiving ones that aren’t being actively developed.
One thing I think you’re overlooking here is the fact that SonarCloud analysis continually gets smarter and continually finds new, “harder” issues. Next month, 6months from now, next year we’ll be detecting things we can’t today. Even if these projects are dormant, it may be worth your while (and your clients’!) to periodically re-analyze and make sure nothing new shows up.
That is a fair point, though in our experience with the products we make, once all of the customers’ testing and compliance requirements have been met, there is a very high cost of making changes and thankfully rarely a need to.
Keep in mind that while it’s a good idea to clean up your project structure, that isn’t a requirement for a ‘correct’ SonarCloud analysis. You can exclude those libraries from analysis. You might want to analyze them in one project, just for your own peace of mind, but then exclude them in all the others.
Don’t tell the salespeople I said this, but there’s no big need to size up now for requirements you’ll have at the end of the year. I would set the license to what you need for now and maybe make a note to re-evaluate at the end of each quarter.