Continuing the discussion from NethServer Community at Fosdem 2020:
I’m just wondering and hope I didn’t misunderstand anything… You notice that there is no significant raising of funds. The consequence of this: You want to commercialize the support even more, so to replace one evil with another.
Why don’t you think about taking over the strategy of successful projects? I am thinking especially of Pihole.
- dynamic and innovative in-house development
- wonderful free support with surprisingly complex support for each individual case
- automated system profiling for support cases (teleporter system with support token)
- well accepted multilevel donation system
- simple user interface, which comprehensively supports - system analysis
- very good use case related documentation
Have you ever seriously considered adapting the Pihole experience as a project?
Please don’t misunderstand me. I appreciate your work very much and my suggestions are not meant to be disparaging.
But there’s always a better way.
In my opinion it is not about rasing funds, but about getting a decent base so the project becomes a viable trusted and sustainable option to use for professional purposes.
In Italy Nethesis, the company behind NethServer, has a solid base, but for other countries this is lacking.
By offering a support program, local integrators can have [professional backup by Nethesis.
Yes this will cost money, but the primary goal is getting en solid and guaranteed support chain.
I do agree we shouldn’t invent the wheel once again and cherrypicking from other (successful) projects is an option we should consider
The subscription could be also more visible in the software center, not a pop up like proxmox, but a statement you are using the community repository at your own risk
orange community edition
green subscription (with the time end of the subscription)
Sure that we are too good and we are really fast to answer to issue and bugs, it is good and bad, it does not push people to take a subscription. There is no sustainable development without incomes at a point, so the professionals should consider to subscribe for their clients, it is one (the good ?) way to fund the development of NethServer.
After that if maybe the companies or the freelances do not take the subscription, I would be curious to understand why, maybe we have missing something
I am not sure about this. More visible: fine! but IMO we must avoid any sign that the community version is not stable or less performant. In fact, it is the same product as the subscription version.
I have seen way too many examples of crippled ‘free’ (as in gratis) versions with the only option to have a stable solution is to pay for a ‘subscription’ or ‘enterprise’ version. We must not go that way!
In my eyes it’s almost grossly negligent to use community repositories in a companies production environment. So I’m curious, how many such installations are out there. Why do they take the risk for that less money? 48 Euros a year is really cheap. Proxmox costs 78 Euros per year and cpu. Also cheap.
My IBM iSeries support costs about 1.500 Euros per year and system and this is a really small system.
But in the last 15 years I had not one single day with downtime with the iSeries. So what’s cheaper??
An functional and stable IT infrasturcure is nothing to have for free.
And also for privat production systems. The time of work to clear the mess, if a bug hits you, is really worth 48 €. I do not see anything evil in payed repositories. That’s a common way.
But why are the support plans are not successfull?
I think one answer is this community itself. The support is here excellent, maybe to good.
That’s good and bad. And the subscrition is not advertised in NS. It should be.
Sorry, I do not agree. The community repo can cause trouble because of untested upstream features or updates. That’s the reason for the tested and delayed subscription repos. The product is the same, but not the level of stability and/or security. If you do hide this difference, I do not wonder that the supportplans are not successfull.
Again proxmox as an example. I can use the community repo on my own risk with updates which dind’t pass the full QA. If something bad happens, I do not have to complain! Everyone accepts this and proxmox is successfull.
I do not see anything bad in having a hint about the subscription and it’s advantages.
Something like “Please consider to buy a subscription to support this community and to avoid eventually issues caused by upstream updates. Thank you.” This is nothing different to the “Please donate” button.
Just my thoughts about.
Maybe so, but in fact community and subscription they use the same repositories…
Really? That’s new to me. Dind’t know this.
I thought point 2 means, that different repos are used.
Why is there a subscrition.repo with username and password and a NethServer.repo without?
If there is no difference I do not wonder that noone buys a subsciption.
Please can you clarify this for me @giacomo or @davidep?
Subscription (and Enterprise) repositories receives updates after community to ensure the stability.
Subscription and Enterprise share the same infrastructure which is different from the community one.
@filippo_carletti talked about 5000 servers not managed by Nethesis or their Partners, so in short
5000 servers give 50 subscriptions of 48€
Yes it is cheap to be sure that updates will hit the community and your servers will be safe, IIRC epel is also provided by the subscription
My estimation comes from the total number of system reported in Phone home, which now is 14449, minus about 12000 systems located in Italy, plus a “random” number of system that I guess opted to disable Phone home (let’s say 2000): so, rounding up, 15000-12000+2000=5000. It may be even less.
I used 5000 as total because it’s 100 times 50, which is the number of active subscriptions, so it easy to say that 1% of the systems have a subscription.
The problem being, that the cron generated e-mail to say that updates are available contains just updates from the Subscription/Enterprise repositories, but using the UI (and I think command line), the files are pulled from the community repositories.
I think it’s possible, in the command line, to force only the Subscription/Enterprise repositories to be used, but IMHO this kind of hoop jumping should not be required. I have a subscription so no matter how I try to update, UI/normal command line, I should get the correct updates applied.
This is not true: you are always accessing the subscription repository.
But automatic updates and UI has 2 different views on the same repositories.
When using a subscription (or enterprise) the admin usually set the automatic update installation.
Such automatic updates are distributed with delay and gradual: the first days only a small percentage of machines receive the updates.
When you access the UI, you install released package despite of the automatic update policy.
This is useful to quickly install hot fix and new features.
I know that @davidep would like to improve such behaviour, at least to make it clearer inside the UI.
There a little bit more complex internals about automatic updates, we will leave it aside for now But if you are curios, just ask … we will need a little time to write down a comprehensive answer
It seems there’s still a lot of confusion around the subscription program. This is consistent with the low number of Crostino out there.
We surely need to improve the web site and shape the product in a better way! /cc @alefattorini
I don’t get why some Crostino users keeps updating the system manually. IMO the real benefit of managed repositories is automatic overnight updates with monitoring.
Manually reviewing the updates is a task for community users.
How many admins use automatic updates on a Production server. I would hazard a guess, very few. They normally want to check what’s being installed and control when they are installed.
I won’t even do that on my home system.
This is perfectly normal sysadmin behavior. I don’t know ANY sysadmin that allows his servers to have automatic updates. And this is quite understandable since a sysadmin wants to have control over what and when updates are installed.
I have been in an environment with over 150 (ssshhhhttt windows) servers that needed monthly updates. You can imagine these updates weren;t updated automagically, but instead a few, less important servers were updated to test those updates. Update process was using broken raid1 so quickly reverting to old situation was possible. Nowadays we would take a snapshot first…
When those ‘test’ servers had no problems, all other servers were updated by the sysadmins commands.
Trust but verify. :)
I tried to sign up a server for an office just to throw a few bucks in the kitty a while back and the paypal failed.
Like smoking. It’s hard to get rid of old habits …
So, let me ask… since i’m about to buy a crostino subscription, what are the best pratice before deploy the firewall ?
Let’s pretend i’ve just finished to install NS via the latest ISO, what are the steps that should i take to be sure to have an updated stable system?
- So on first boot, finish the configuration with the wizard.
- Add the registration key
- Hit the update button ??
- Install the additional application needed??
- Finish the configuration of the additional application
So, i should not hit that update button on step 3 to ensure that i’m using the “stable” repo and let the firewall do the update overnight?
I don’t wanna deploy the machine till i’m sure is working the way i want with the latest avaible “stable” update, and ofc i don’t wanna “ship” a firewall with 6 month old updates couse i’m scared to hit the update button
What if i install and configure everything and then when the firewall get shipped to costumer facility ( maybe after 10 day or so ) an automatic update screw up something ?
Can you guy just guys make the behaviur of the update like proxmox ?
They just give free access to community update ( you just need to enable the repo wiki), and once you buyed the subscription, revert to the enterprise repo and every time you hit the update button from ui or apt dist-upgrade, you get the tested update.
Can you make the update button (aka manual update) behave according if you have a subsciption or not ? If sub on = pull tested, production ready || sub off = community repo, testing repo ?