4 ms·

This sounds interesting, but doesn't make much sense. Do you mind explaining a bit more?

Stwerner 13y ago
Interesting to see this here, I had this idea a while back and have been discussing it with people before I go on validating/invalidating it. In my mind anyway, the idea is something like https://railslts.com/ https://railslts.com/ but for potentially every other gem in your gemfile. We would provide security patches, bugfixes, features, documentation, training, version upgrade scripts/documentation and so on to subscribers. I really like the accumulated credit for features, maybe a system of like: request feature, we put a "credit" value on the complexity of the feature, then companies/people can pledge credits/money for it would work?
- th0br0 13y ago
  I've also had this on my mind for quite some time. How would you actually implement things though? After all, you're essentially trying to sell "support contracts" for open source projects via the platform. You could implement these by a) "hiring" the project owner to work on specific bugs/features or b) hiring freelancers to fix requested bugs. Furthermore, how would you ... * determine the value of bugs/features? * react to a project owner abandoning a project? * handle multiple upstream developers?
  - zimbatm 13y ago
    One important part as a provider would be to have a way to collect all the dependencies on which a customer depends on. This helps you priorities your maintenance work if the customer doesn't have any requests (auto-pilot mode). Is is also useful as way to sell: "see all the things you depend on". And finally it lets you take decisions on which project maintainer to poach.
  - Stwerner 13y ago
    I hadn't really cracked how to scale the business up, but to bootstrap it I was thinking that I would just do the work until it became too overwhelming. I haven't thought about what pricing would look like, so I don't know how feasible it would be to just hire more people as more and more work comes in - but it should have some interesting economies of scale since there is a lot of overlap in the gems used in rails projects for instance.
zimbatm 13y ago
It's a way to shift the value proposition. Nobody in their right mind is going to pay for free things. You can try to appeal to people's good will in funding rounds but it requires a recurring effort that detracts from the work. This is because we still have the view of software as being a thing you get in a box. A specific delivery that you use for a while until the new version is on the market. This is how proprietary software like Microsoft Office is structured. Now in practice, software is never a done deal. You have bugs. Platforms evolve and you need to adapt the software to it. New features might be added. This is all things you might want to see happen in the future. A subscription service could be a way to participate in the process indirectly. Obviously things need to be balanced as to not corrupt the projects in question. There are already actors in the place like RedHat and Canonical or product companies like MongoDB but they are focused on their platforms and usually sell "support". As a customer I have a big and changing variety of open source project upon on I depend and negotiating contracts with each of those is time consuming. I would rather pay a fixed amount and have access to a body of experts and direct (part of) their work on projects they own or not. If I scale my subscription up I get more throughput. A lot of details are conveniently left open to keep the narrative simple and idealistic :)

Interesting to see this here, I had this idea a while back and have been discussing it with people before I go on validating/invalidating it. In my mind anyway, the idea is something like https://railslts.com/ https://railslts.com/ but for potentially every other gem in your gemfile. We would provide security patches, bugfixes, features, documentation, training, version upgrade scripts/documentation and so on to subscribers. I really like the accumulated credit for features, maybe a system of like: request feature, we put a "credit" value on the complexity of the feature, then companies/people can pledge credits/money for it would work?

th0br0 13y ago
I've also had this on my mind for quite some time. How would you actually implement things though? After all, you're essentially trying to sell "support contracts" for open source projects via the platform. You could implement these by a) "hiring" the project owner to work on specific bugs/features or b) hiring freelancers to fix requested bugs. Furthermore, how would you ... * determine the value of bugs/features? * react to a project owner abandoning a project? * handle multiple upstream developers?
- zimbatm 13y ago
  One important part as a provider would be to have a way to collect all the dependencies on which a customer depends on. This helps you priorities your maintenance work if the customer doesn't have any requests (auto-pilot mode). Is is also useful as way to sell: "see all the things you depend on". And finally it lets you take decisions on which project maintainer to poach.
- Stwerner 13y ago
  I hadn't really cracked how to scale the business up, but to bootstrap it I was thinking that I would just do the work until it became too overwhelming. I haven't thought about what pricing would look like, so I don't know how feasible it would be to just hire more people as more and more work comes in - but it should have some interesting economies of scale since there is a lot of overlap in the gems used in rails projects for instance.

zimbatm 13y ago

It's a way to shift the value proposition. Nobody in their right mind is going to pay for free things. You can try to appeal to people's good will in funding rounds but it requires a recurring effort that detracts from the work. This is because we still have the view of software as being a thing you get in a box. A specific delivery that you use for a while until the new version is on the market. This is how proprietary software like Microsoft Office is structured. Now in practice, software is never a done deal. You have bugs. Platforms evolve and you need to adapt the software to it. New features might be added. This is all things you might want to see happen in the future. A subscription service could be a way to participate in the process indirectly. Obviously things need to be balanced as to not corrupt the projects in question. There are already actors in the place like RedHat and Canonical or product companies like MongoDB but they are focused on their platforms and usually sell "support". As a customer I have a big and changing variety of open source project upon on I depend and negotiating contracts with each of those is time consuming. I would rather pay a fixed amount and have access to a body of experts and direct (part of) their work on projects they own or not. If I scale my subscription up I get more throughput. A lot of details are conveniently left open to keep the narrative simple and idealistic :)