As a user, part of the motivation for FOSS is that it has no direct cost. This is fundamental to the model: everyone shares the output, everyone contributes to the input (be it through advocacy, bug reports, community support, patches, major development effort, or whatever).
If I use some FOSS component, I know that if I use it in the usual way, there's a community of others doing similar things that I can ask if I get stuck. I don't expect to pay for that (nor do I expect payment for my own contributions to those discussions).
I don't want to pay for a "support contract" for FOSS.
- First and foremost, that's not the model: if I want commercial software, I can buy it already
- I use way too many components to manage support for all of them
- Many of the components I use are too small to warrant paid support at a practical level
- Most of the time, it works just fine anyway
- When it breaks, I'm usually happy to fix it myself and contribute that back (and that's the indirect cost I'm happy to pay).
I am willing to contribute to community costs: funding eg. Python Software Foundation, Software Freedom Conservancy, etc, on an annual basis.
I am willing to pay "support aggregators", eg. RHEL licenses. My expectation there is that I have one support contract that covers everything shipped with the OS, and that Red Hat will use their aggregated income to perform my community obligations (and do better because they're full-time experts in a team). I pay extra for convenience, and they take a profit.
I also strongly support a bounty-style model. I'm happy to pay someone (either by tasking an employee, or contracting an external developer) to add significant new functionality, or to tackle a backlog of maintenance, or to start a new project.
I agree that the bounty-stye approach works well for encouraging new development. I'm thinking about the times when you get stuck: the community boards often do not have exactly what you need and it can be tough to explain your issue and slow to need to wait for replies.
In these cases, having a synchronous discussion with the right person could save a lot of time. For smaller projects, I think a pay-per-time approach would work better than support contracts.
From a FOSS-user point of view, having a pre-established commercial relationship is good: no-one wants to get approval to spend money on a per-incident basis. After that, having a per-hour model to get good-quality support would be good. If there was a place that I could find someone with the right expertise, recommendations, etc.
As a maintainer, this would fine too. I'd likely not offer paid support myself -- I have limited time available, and I'd rather be looking after the small queries, and doing the development I want to do rather than doing paid support work, but I'd be really happy for someone else to get paid to do it.
I should point out that this has been tried before ... see Cygnus Support, LinuxCare, etc, etc. I don't know of any recent attempts though.
If I use some FOSS component, I know that if I use it in the usual way, there's a community of others doing similar things that I can ask if I get stuck. I don't expect to pay for that (nor do I expect payment for my own contributions to those discussions).
I don't want to pay for a "support contract" for FOSS. - First and foremost, that's not the model: if I want commercial software, I can buy it already - I use way too many components to manage support for all of them - Many of the components I use are too small to warrant paid support at a practical level - Most of the time, it works just fine anyway - When it breaks, I'm usually happy to fix it myself and contribute that back (and that's the indirect cost I'm happy to pay).
I am willing to contribute to community costs: funding eg. Python Software Foundation, Software Freedom Conservancy, etc, on an annual basis.
I am willing to pay "support aggregators", eg. RHEL licenses. My expectation there is that I have one support contract that covers everything shipped with the OS, and that Red Hat will use their aggregated income to perform my community obligations (and do better because they're full-time experts in a team). I pay extra for convenience, and they take a profit.
I also strongly support a bounty-style model. I'm happy to pay someone (either by tasking an employee, or contracting an external developer) to add significant new functionality, or to tackle a backlog of maintenance, or to start a new project.