We have many feature requests that have build up over the years, some for a niche thing others for something that would benefit many users. Many have been implemented but enough remain to be a significant number. And from one perspective every open issue is one too many. But I've learned over the years that not everything can be solved. I speak of 'we' as in the wider group of ISPconfig users, not only the developers. I personally count myself somewhere in between. I do supply patches every now and then, but do not have the time to closely follow development. Not all users understand how it works in free software, but as long as we're not paying a yearly fee we can't expect development to do happen like magic. (True, even with commercial products you often have very little influence) ... but here someone spends their own time. I assume that most develop it because they have a personal benefit from it, either for work or private hosting. Motivation can go a long way but some changes are more interesting than others. The best way to get your need fixed is still to do it yourself... or hire someone who has the right skills. Then you are in full control to dedicate time to get things done.... (as long as you can convince others that it's an improvement overall). Besides that someone has to be motivates to do the work. The founder of the Drupal project has several in-depth blog posts about this topic on https://dri.es/ e.g. https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source can be worth the read. How can we motivate our community to keep improving, and maybe even accelerate. There have been many bounty and fund raising systems. These have come and gone with varying degrees of success. Patreon.com seems to be in the lead these days. (at least in my filter bubble) There are some recurring revenue streams going into the project. What we have: ISPprotect HowtoForge subscriptions which give access to ISPConfig 3 Priority Support forum Business Support on https://www.ispconfig.org/get-support/ Billing module Migration toolkit I'm not sure how much developer time that pays for... but maybe we should promote the 'Business Support' page when there is a feature request in the forum or on Gitlab? Some other options are: bug bounties? tip jar Patreon Paid plan (with some form of support offer) Raising some awareness on 'bug tasks' to raise funding and rally users. Raising funds in the free software world is not easy, but we can do it! My goal with this post is to start a discussion. It may give some negative reactions when a feature request is met with a link to a funding system but maybe it will also help to set a realistic view of how much effort it takes to maintain a piece of software. Thanks to all who have contributed to this great piece of software so fare.
ISPConfig is a great software. It keeps all the system changes very clear, not doing mess in the configuration, easy to customize etc. We built our business on the ISPConfig basically. We are open to share or contribute to ISPConfig development much more but from my side of view, there are on any clear rules or perspective regarding ispconfig contributing. From my side of the perspective, I would appreciate some clear plan or way regarding contributing. In the ISPConfig is a lot of features, much of them undocumented (no manual or documentation) as well as from developers perspective as from users perspective. So, we are ready to help and contribute more with ISPConfig development but we need some more contact or communication between core team against developers and contributors and some work on manual or docs. There should be clear concepts from the core team, list of features, what is core team vision.
From my perspective I would appreciate a kind of bug bounties as financial reward for contributers and with a share for the ISPConfig maintainers as support for the entire project. I see bug bounties as a way for users to vote for features they really need. How fast can you vote up features in Gitlab. You won't place that many bounties This way, contributers and newly joined developers can get a reward for solving problems that are important to other users. And as further incentive for the bug bounty, a bounties share that was paid to project maintenance could be credited for HowtoForge-Subscriptions. Yeah, definitly. Maybe ISPConfig UG could further offer support contracts for the productive use of ISPConfig in companies. No one knows better about the core of our favourite control panel than Till and Falko. This way they could generate direct income for their company and develpment and maintenance of ISP.
I agree users desire new features, but I am more conserned with the not so perfect state of documentation. I see from old forum entries that there has been ISPConfig Wiki, but it does not exist anymore. Something like a wiki or other way to have documentation kept up to date would help. For example the ISPConfig update FAQ does not state for multiserver setup if the master should be upgraded first or last (it is in the comments). These kinds of small improvements for documentation should be made easy to contribute. When important info is only in the comments, it is hard to know if it is reliable. I admit a wiki may not be a good solution. When I first heard about Wikipedia I thought a system where anybody can write is filled with garbage i no time. I was wrong, I did not know there were so many editors willing to clean up wikipedia contributions.
Basically that is by joining ISPConfig gitlab where you can request @till for that access. The problem will be the contributors will not know the developers' priorities, preferences and plans, and their proposals or suggestions may be left unattended and/or unvisited for days, weeks, months and even years. This will definitely cause the contributors to get bored and fed up thus leave indefinitely and that personally happened to me. I really hope it won't happen to other contributors especially those who are young and eager to help.
Thank you to all that participate in this thread to raise awareness that OpenSource projects need funding as well. We currently have some funding as @helmo pointed out in the list, this is enough to keep the current status. But the current status also means that things are as they are like missing docs, long code review times etc. due to the lack of time as all core devs have to earn a living mostly with other, non-ispconfig related, projects. Providing support is, of course, the most common mentioned income source for an OS project, but this comes with the huge drawback: you get paid for the time you do the support, this means you can not work on ISPConfig in that time, and support is not that well paid if as that you have money left over. ISPConfig has users all around the world, every user expects to reach the support during his business hours, so you'll either have to stop sleeping or you must hire a whole team that works 24/7 and will cots you way more that what you would earn with ISPConfig support. Probably a working funding option might be a non-free ispconfig business or 'pro' edition that contains features tailored for multiserver and business use that includes also existing addons like the billing module and free use of the migration tool when migrating to or between pro versions. You can reach me here in the forum and by email at any time, so not sure why you claim that you can't reach any core devs. Things that are on our todo list are tagged in the git, so they can be found easily. See e.g. tags 'planned features' and 'stable-3.1'. The best way to start a larger project inside the ISPConfig code base is to make a thread in the dev forum, describe what you want to do and how you want to implement it. The core devs and other users can then comment on this before you start coding. This helps to avoid that we have to discard an implementation due to coding issues or because it does not fit well in general. This might be a way indeed, but it might become a huge task to organize that and in the end, many users that promised to pay something will probably not pay when the issue is solved. I did that in the past, the result was that I did not had any time to do ISPConfig development as I can not do support and the development, a day has just 24 hours. That's why I stopped providing support myself. And companies want 24/7 contracts, you can't do that without having several employees just for providing the support, but the amount of support that is requested would not even enough to pay one employee. ISPConfig business support is available and provided by Schaal @IT now and the ISPConfig projects is supported financially by Schaal @IT. A wiki does not work, we had a wiki and it was filled with trash and spam within a few days. But I agree that we have to improve on the documentation side. that#s why we put e.g. the developer docs in the GIT, so anyone can contribute easily. But there are nearly no contributions to it, as you can see.. These can be found in the GIT system as well, we tag the issues for the various releases, search e.g things tagged for stable-3.1 branch. Many third-party contributions are disruptive in a way that they are incompatible with existing setups or would simply break the whole installation base or the code quality is not ok. That's why I always ask contributors to contact me and discuss how something can be implemented in the right way to get accepted, but not all contributors do that which might result in the end that we have to reject a contribution to protect the codebase. We handled that not as strict in the past and had later many issues with that, which means I worked months to fix the codebase to be able to get a release out at all. Many contributors don't take this into account when submitting their code, but we have to care about that. Also contributions might get tagged for 3.2 instead of going into stable branch. That's actually not the case, we review contributions within a few days. But I agree that we did not tagged them all for being under review, but this has been changed already as well. and regarding some of your contributions which are pending, they are tagged to be included in 3.1.16, some things get merged when I do tests on the installer anyway for implementing a new release, but I informed you that the changes will make it in 3.1.16. I'm sorry to hear that.
Sure 24/7 global support is very nice but I think a lot of users will understand a 1 european business day responsetime. And I don't see Schaal IT offering 24/7 either. But support is a different game so I completely understand that you prefer to delegate that to Schaal IT. We could improve the page on https://www.ispconfig.org/get-support/?type=ispconfig with some more info or links though. Such a form will be a dead-end for a lot of vistors that have no concrete question. And some might be scared to ask.. fearing a high price. The site https://schaal-it.com/ispconfig/ has a lot more info to offer and starting at 40,- euro for a half hour sounds like an affordable entry point. The fix for that is a funding platform that takes the money upfront to keep it in escrow. One example is https://www.bountysource.com It's integration seems to be limited to GitHub though. Another is https://gitcoin.co but also limited to GitHub until https://gitcoin.co/issue/gitcoinco/web/2169/2459 is made into a reality. GitLab also has an open feature request for it on https://gitlab.com/gitlab-org/gitlab/-/issues/21353 https://www.ispconfig.org/development/ has a 'Roadmap for ISPConfig 3.1' link that goes to the 3.1 milestone .. which is complete. It might be good to update that to https://git.ispconfig.org/ispconfig/ispconfig3/-/milestones/68 for 3.1.16 or add a link to the milestones page https://git.ispconfig.org/ispconfig/ispconfig3/-/milestones to avoid having to update it with every release. And maybe a link to the stable-3.1 label ...
perhaps if there was other similar places in America and Asia that were willing to provide similar support options? you could them provide a 'follow the sun' support option, a central ticketing system that routed support requests to schaal-it during 9-5 cet/cest, route them to US support for the next 8 hours, and then asia for 8 hours before returning to Europe. that way everyone gets office hours support. any unfinished started support tickets can be continued out-of-hours by the same support, paused until the same support returns, or handed over to the next time zone support on an individual basis. unstarted existing support tickets can be taken up by the incoming timezone, if the support requester is still open/available. would require co-ordination and co-operation between the support people/companies in each timezone, and set conditions about splitting fee's for support that has been provided across timezones. but should be doable. also perhaps, an extension to this, a fully managed support option provided by those 3 companies. any issues/alerts that ispconfig finds automatically get reported to the support companies, who can take a look and take action as necessary. would obviously cost more to purchase this level of support....
Yep, and much kudos and THANKS to those developers, like Till and others, who stay the course. It's easy for people to "come and go" as suits them. I do the same, and I know from other projects how frustrating it is to plough lots of energy into something and then to find newbies first enthusiastic and then "bored". This symptom is soul-destroying for the maintainers, and the only fix is to keep your eye on the long-term and plough on regardless of the people who come and go. In fairness we all have different priorities at different times, too. I know this (coming and going) wasn't the only point you were making, but it's an important one. In terms of finance, one solution is to find a "patron", like in the good old days of yore
One idea would be to keep ISPConfig free for single server setups, and require a license for multiserver setups. People that contribute to ISPConfig as dev (or anything like it) get a license for free. This way, we would also motivate some bigger hosting companies to contribute to the project. Right now there are big companies that use ISPC for free and develop functions that would be useful to the whole community, but they keep them for themself (why would they share it, other then goodwill?)
that seems a bit harsh, not all those using it multi-server are big companies, it would also penalise those that just want to separate services across servers. besides which, dns should (ideally) be run on at least two servers, so really everyone using ispconfig servers for dns rather than an external service provider should be running it multi-server, albeit one of them only needs to be a very small instance for dns only. it's also eminently possible that one very large top-of-the-line server could have more cpu, ram, and load capacity than someone else using several small vps's. perhaps a fairer method would be it being free on servers below a set number of cpu's/vcpu's, or if the number of servers exceeds say 10 instances. I'd also suspect that even for the larger companies, a large part of ispconfig's appeal is not just it's ease of use and relative simplicity/cleanness of interface, but that it's free, and if it started being charged for, I suspect they would then consider going back to more commercialised options like Plesk, where they would be able to get the sort of support and service level arrangements expected of commercial software that the ispconfig developers just don't have the revenue to fund. now if there are some bigger companies out there developing features which they keep to themselves, perhaps a better option would be where ispconfig had a well developed and documented method of developing, adding and removing plugins/modules so that features/capabilities can be easily added and removed from the system as required. perhaps then there would be more of an incentive for them to release those plugins on a commercial/licensed/paid support basis.
Bug bounties: I like that idea. But more for security bugs and not "general bugs". The question, however is, how financially strong is the project to be able to offer such security bug bounties. I guess I can safely assume that this project is not as financially strong as Mozilla for example. So, if there will ever be security bug bounties then we are probably talking just about pocket money. Tip jar: I like that idea too. Paypal button? Patreon: I'm not really a Patreon person but maybe it's possible to offer this option as an alternative to the Howtoforge priority support. I've seen other persons and organizations using Patreon and offering their Patreon supporters additional goodies around their work. Maybe it's possible to build some Patreon packages which could contain for example: Howtoforge priority support, the manual and the migration toolkit included, lets say for 15€ per month for over the course of one year. I hope you guys get the idea. Such a package doesn't have to look exactly like that. Regarding rallying users: Something that comes to my mind is the ability to fund certain features. That way it would be possible to speed-up the implementation of a feature which might have high demand but for whatever reason is still not implemented in ISPConfig. For example how Bareos is doing it: https://www.bareos.com/en/co-funding.html
Ah. I understood that money is not the only problem, time is the other one. But if there were enough developer-time available that could be paid with money, then perhaps co-founding like the german company UIB does might be a way: 1) They estimate the (money) resources they need to implement a requested feature and publish the calculation 2) Start development with payed developers until the feature is usable 3) Allow usage of the new feature only to people how pay at least a certain amount. 4) If the sum of these payments reaches the calculated development costs the feature is released for free use for everyone. It is a bit like the Street-Performer-Protocol from Bruce Schneier. A drawback might be that this locks out any voluntary developer outside the maintaining company. Another disadvantage is that the company must take the costs in advance, hoping to get the money back. Gerd
