@sergey,
In response to your post the following, with quotes (to keep some distinction).
While we are not really going into open source, there is actually way to customize Plesk widely via its
SDK. As you can see in the available extensions (
https://ext.plesk.com/) - it allows a lot of various stuff implemented.
To be honest, it is showing a lack of extensions (several years after the introduction of the SDK), given the fact that Plesk Panel is widely implemented.
Again, to be honest, the above can also be reflecting the fact that a lot of the extensions are not required, i.e. out-of-the-box Plesk is good enough.
Unfortunately exposing whole Plesk core would be very hard to maintain by now - a small fix can perfectly work in a particular environment, but we have to run tests on several hundreds of possible setups. However we consider putting certain parts of Plesk on github, so that those parts can be branched and tuned by volunteers.
This would certainly be wise for testing compatibility of new Open Source packages, since it is a minor task to install those packages and "see what happens" (and by using the Github project page, the parallels forums would be containing less "alleged error" messages).
Maybe the core Plesk code cannot be shared, from a company´s (i.e. Parallels) perspective).
However, some of the code is already residing on the server, after installation, giving the possibility to tweak some of the code.
A Github project page would then create a more streamlined method of coördination.
By the way, any Github project initiative should be implemented properly (for instance, the
https://github.com/plesk/api-examples is not an effective way of doing things).
Over time bugs, failed operations or improper customizations/workarounds may leave some "trail" - i.e. some internal records will remain disconnected or not fully removed, or keep it in other form of inconsistent status. So there will be a scanner walking through the internal data structure, matching against proper data patterns and then reporting/fixing issues discovered.
Sounds very good! Primarily the part of reporting issues would be a nice enhancement.
Problem and/or challenge would be (again) the "zoo of OS-es" supported.
You are absolutely right that those scripts can be developed out of Plesk and we are aware of several proprietary scripts doing this job for some providers. They are quite huge sometimes. In many other cases it would be a preconfigured image, maybe even manually tuned, and then used for producing 100s-1000s of servers.
Forcing some "ideal" configuration from Plesk would definitely conflict with such tunings and will put unnecessary responsibility on us, so we would rather have it as "optional" for those who cannot have advantage of skilled admin or pre-tuned setup.
In general, I noticed that many "advanced Plesk users" are willing to share knowledge, scripts etc.
The general problem here is that a platform for sharing (code, scripts etc.) is not available, with the one exception of this forum, giving rise to the pitfall that individual and/or stand-alone issues are targeted (and after some period, one really does give up, if some issues continuously re-emerges).
Is a "sharing platform" a good idea?
In the light of the above, some standard customization can be assigned to the community, without Parallels being involved and/or responsible.
This is discussable.
Being big company applies certain constraints on how we operate, but there are always some options.
i.e. we could start with something lightweight - opening special forum for patch proposals. A lot of scripts in Plesk are open and can be patched. We can probably review, adjust to our policies and include into the next update. More than that - we could probably accept config patches and convert them into code on our side.
Actually many admins have very extensive scripting over Plesk (but not everyone would want to share them).
If there will be big enough activity at this level, we can consider moving to next step.
Does it sound reasonable to you?
Stating the obvious: yes, it sure does.
However, some words of caution are needed here:
a) Patches and config patches should be distinguished, for many reasons, amongst others that config patches are often subject to opinions (i.e. preferences of the admin) or situations (set-ups, OS-es etc.), implying that config patches are not and/or should not be the most important and, even when applied, should be carefully reviewed for general applicabilty and overall desirability,
b) Patch proposal (not being config patches) should be considered as a potential danger, leading to development outside the code of a lean-mean-and-efficient Plesk Core, as such not in line with the (proper) goal of improving the Plesk Core itself,
and, as a result, one (i.e. Parallels primarily) should guide the process of development, being either patch or other development.
In a certain sense, the opening of a special forum for patch proposals is only a starting point, but it can be reasonably expected not to be an effective one, given the above and the fact that it will give rise to "ideas" and less to "code", let alone "guided code development" (allowing realisation of the desired patch).
But then again, keeping in mind that we need ideas, the special forum is required and, in combination with some Github (patch) repo, we should get where we want.
By the way, the "advanced admins" you are talking about, those persons are more likely to share code on Github than on a special forum, given the general purpose function of Github and the absence of limitations of specific questions on the Parallels forums (by which I mean that most of the generic, simple issues reported on these forums do not require an extensive, highly advanced script as created by many "advanced admins").
A final note, you are aware that opening up for patch proposals can also increase the number of problems regarding stability of Plesk?
We are available actually. You can find Plesk in Amazon catalog.
For Digital Ocean and Azure their policies don't let us to put pre-made images, so we have some guidelines in the internet:
I am aware of Plesk in the Amazon catalog and the internet guidelines.
However, the Azure (internet) guidelines are targeted at Windows (and not Linux) and, furthermore, Amazon and Azure and Digital Ocean instructions are concerning creation and/or usage of images for Plesk.
The above (obviously) does not include and/or embrace the full possibility of the cloud.
Moreover, the inherent dangers of the cloud are not mentioned at all.
For instance, automatic scaling of a VM on Azure is not possible with custom images.
In short, there is (at least) a huge gap in the documentation.
In addition to the above, the following.
Plesk can be made to run on multiple (clustered) VMs in the cloud, even though it is rather difficult (not impossible) to make the installation proper and stable.
Parallels should be aware that the one-machine-one-license model is out of date, given the recent developments in the cloud.
I would rather have clear instructions regarding cloud setup (not instructions on how to setup Plesk on a single VM, that is straightforward and almost equivalent to installations on a single dedicated server) AND (code-based) support for cluster-based cloud setup (on multiple VMs).
The idea should not be that a deployment in the cloud becomes a single-instance Plesk Server.
The idea should be that deployment in the cloud becomes a choice between various deployment methods: cluster, fail-over, load-balanced etc.
In my humble opinion, the above is a highly ideologic target on my behalf, but one that should fit into Parallels future targets nicely.
And, in a sense, in realising this target, some work can be done by the community, which can be expected to contribute happily to this target (that is my firm belief).
Kind regards....