5 ms·

Having spent some time on the problem I agree generally with your approach, but the problem is it doesn't appreciate the history and context in which the curren

Having spent some time on the problem I agree generally with your approach, but the problem is it doesn't appreciate the history and context in which the current system has arisen and continues to exist. There are basically 3 cases of successful FOSS projects: 1. Ideologically-driven, e.g. Emacs, GNU, etc. These tend to have licenses in the copyleft family 2. Commercially-driven, e.g. WebKit, Docker, etc. These are projects that are strategically important to one or several companies. They tend to have licenses in the MIT/Apache family 3. "Lone Wolf" or "indie developer". While a lot of FOSS is this by volume, what you discover is that by the time projects become popular they have generally evolved into one of the first two types, although they often preserve their creation story as part of the marketing material The problem with charging money for code is that it's really a bad deal for the first two types. The ideology camp doesn't want non-commercial licenses because it's a "restriction on a field of use" which they have a philosophical objection about that you can google. In the second camp, the corporate masters derive some kind of strategic advantage from having a popular open-source project and charging money necessarily means the project would be less popular and so of less strategic value. What this necessarily means is that if there's any legs to this plan, positioning it as "open source" or to the "open source community" is exactly the wrong approach, because basically all the people who are successful in that community will find it a nonstarter. Instead you have to hypothesize that there's some completely different set of people that can benefit from this system, writing completely new software (or releasing pre-written software that isn't currently considered 'open source', e.g., proprietary software). So your positioning needs to be something like "proprietary 2.0" or even "third way" rather than being connected with open source. The real problem with this system is that I'm not sure there's a market on the buying side. Developers are used to getting things for free, and even if somebody wrote a source-visible-but-pay-$1k-to-use-it high-quality TLS library I'm not convinced that people wouldn't just keep wrestling with OpenSSL because it's free. I have a whole blog post I'm drafting on this topic, if anyone reading this comment is interested, give me a shout and I'll give you a preprint.

pdkl95 12y ago
This kind of situation where there is a common need for something, but there isn't a reasonable way to pay for it in individual transactions has a traditional solution: make the project publicly funded. As an example, a military is a useful thing to have for protection, but paying for it as some sort of subscription or "per-invasion" billing is obviously not a realistic solution. So we fun it publicly, as a tax, which generally works[1]. Similarly, it might be useful to make a publicly-funded service that is charged with creating software infrastructure such as TLS or even libc that are difficult to fund directly. There are a few advantages to using public funds: unlike traditional Free Software, as it uses public funds, the output would be public domain, and usable by anybody, commercial uses included. Also, as it doesn't have to worry about VC money drying up or "maximizing shareholder value", it would be easier to stick to a mandate that emphasizes quality instead of time-to-market. On the other hand, problems with this idea would be the general concerns about corruption due to political meddling, and how to keep the NSA from pulling a BULLRUN on it like they did to NIST. <speculation> Perhaps a "dept. of software infrastructure" could take over the "defense" side that the NSA seems to be neglecting recently. Moving all industry interaction (and trust) over to the new, open group so the NSA was known as spying-only might improve the relationship a bit... </speculation> I'm not sure if this is a particularly good solution to the problem, but it's worth considering. [1] Of course, there are details to argue over and bugs in the system to fix, just like any complicated project.
- Flimm 12y ago
  There's a free-rider problem if the funding is from a national funding body. Since software is generally useful globally, the funding body would have to be international.
  - edraferi 12y ago
    Free-riding would be an issue, but not necessarily a fatal one. As long as the national benefit equals the national expenditure, it'll work.
  - pdkl95 12y ago
    Some sort of international version would be a good idea, if some reasonable plan could be created. Regarding "free-riders", consider compatibility and interoperability. Some amount of "free riding" may be desired if it means you don't have to spend as much time and effort making things work together. These benefits may not be as important at the application level, but for infrastructure, these can be very important features.
sokoloff 12y ago
The real problem with this system is that I'm not sure there's a market on the buying side. Developers are used to getting things for free, and even if somebody wrote a source-visible-but-pay-$1k-to-use-it high-quality TLS library I'm not convinced that people wouldn't just keep wrestling with OpenSSL because it's free. Moreover, (far) fewer developers would base another complimentary project (open source or commercial) on that new $1K-to-use TLS library, because now their new project would be encumbered by a $1K hurdle that brought them neither revenue nor glory. So, they'd continue to wrestle OpenSSL in order to further the adoption of their own package.

pdkl95 12y ago

This kind of situation where there is a common need for something, but there isn't a reasonable way to pay for it in individual transactions has a traditional solution: make the project publicly funded. As an example, a military is a useful thing to have for protection, but paying for it as some sort of subscription or "per-invasion" billing is obviously not a realistic solution. So we fun it publicly, as a tax, which generally works[1]. Similarly, it might be useful to make a publicly-funded service that is charged with creating software infrastructure such as TLS or even libc that are difficult to fund directly. There are a few advantages to using public funds: unlike traditional Free Software, as it uses public funds, the output would be public domain, and usable by anybody, commercial uses included. Also, as it doesn't have to worry about VC money drying up or "maximizing shareholder value", it would be easier to stick to a mandate that emphasizes quality instead of time-to-market. On the other hand, problems with this idea would be the general concerns about corruption due to political meddling, and how to keep the NSA from pulling a BULLRUN on it like they did to NIST. <speculation> Perhaps a "dept. of software infrastructure" could take over the "defense" side that the NSA seems to be neglecting recently. Moving all industry interaction (and trust) over to the new, open group so the NSA was known as spying-only might improve the relationship a bit... </speculation> I'm not sure if this is a particularly good solution to the problem, but it's worth considering. [1] Of course, there are details to argue over and bugs in the system to fix, just like any complicated project.

Flimm 12y ago
There's a free-rider problem if the funding is from a national funding body. Since software is generally useful globally, the funding body would have to be international.
- edraferi 12y ago
  Free-riding would be an issue, but not necessarily a fatal one. As long as the national benefit equals the national expenditure, it'll work.
- pdkl95 12y ago
  Some sort of international version would be a good idea, if some reasonable plan could be created. Regarding "free-riders", consider compatibility and interoperability. Some amount of "free riding" may be desired if it means you don't have to spend as much time and effort making things work together. These benefits may not be as important at the application level, but for infrastructure, these can be very important features.

sokoloff 12y ago

The real problem with this system is that I'm not sure there's a market on the buying side. Developers are used to getting things for free, and even if somebody wrote a source-visible-but-pay-$1k-to-use-it high-quality TLS library I'm not convinced that people wouldn't just keep wrestling with OpenSSL because it's free. Moreover, (far) fewer developers would base another complimentary project (open source or commercial) on that new $1K-to-use TLS library, because now their new project would be encumbered by a $1K hurdle that brought them neither revenue nor glory. So, they'd continue to wrestle OpenSSL in order to further the adoption of their own package.