4 ms·

A subscription service for open source projects. As a company I would pay you monthly and get access to bug and features development for all the open source de

by zimbatm 13y ago

A subscription service for open source projects. As a company I would pay you monthly and get access to bug and features development for all the open source dependencies that I am using. The more I pay the more things I can get done in a month. If a feature is too big for my budget I can accumulate month to month value on a ticket or get other companies to participate.

tectonic 13y ago
I like this.
karangoeluw 13y ago
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 :)
allworknoplay 13y ago
I'm not taking a side (really!), but there's a lot to be said for keeping open source projects strong on their own without injecting cash. Cash coming in creates a disincentive to develop without cash and promotes a reliance on paid services rather than a mentality of contributing back. Also, when it comes to many projects, the organization that offers services around them has a negative incentive to contribute clear, quality code.
- ggchappell 13y ago
  > ...there's a lot to be said for keeping open source projects strong on their own without injecting cash. Money is already all over the open-source world. Many smaller projects will not involve it much, but it matters in the larger ones. E.g., much of the code contributed to the Linux kernel comes from people who write it as part of their jobs. That means that feature additions & bug fixes in Linux will be largely those that matter to (say) Red Hat. This idea offers a way to get work I want done prioritized without needing to know how to do it myself. It also offers the possibility of software development midway between the start-up model that groups like YC and Kickstarter are pushing, and the no-money-involved-ever model. Surely somewhere between the two we might find something workable. > Also, when it comes to many projects, the organization that offers services around them has a negative incentive to contribute clear, quality code. A good point. I don't have an answer for that one.
- Stwerner 13y ago
  > Also, when it comes to many projects, the organization that offers services around them has a negative incentive to contribute clear, quality code. I'm probably being naive, but in my version of this idea, I was thinking that contributing well-written, tested, and documented code back upstream from the company's account would be a good way to have the work that's done contribute to the marketing. Part of the reason why I haven't moved past just talking about this idea is the possibility of it having a negative impact in terms of the original creators/maintainers, so I'm definitely interested in hearing more about this perspective on it.
yaur 13y ago
I believe this is called a RHEL subscription... in seriousness though this is a good idea and wouldn't be that hard to put together. You would monetize it by taking a cut of the spend and passing the rest on to the projects.
lukeholder 13y ago
is this what you are meaning? https://deps.io/ https://deps.io/
- zimbatm 13y ago
  This is a good start. Once you have all the customer's dependencies it becomes easier to offer value-added services like maintenance and feature development.
devinrhode2 13y ago
This is a lot like gittip and BountySource. Furthermore, a project maintainer could put on his README, that, for a certain recurring donation, you get some level of direct personal contact.

by zimbatm 13y ago

tectonic 13y ago

I like this.

karangoeluw 13y ago

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 :)

allworknoplay 13y ago

I'm not taking a side (really!), but there's a lot to be said for keeping open source projects strong on their own without injecting cash. Cash coming in creates a disincentive to develop without cash and promotes a reliance on paid services rather than a mentality of contributing back. Also, when it comes to many projects, the organization that offers services around them has a negative incentive to contribute clear, quality code.

ggchappell 13y ago
> ...there's a lot to be said for keeping open source projects strong on their own without injecting cash. Money is already all over the open-source world. Many smaller projects will not involve it much, but it matters in the larger ones. E.g., much of the code contributed to the Linux kernel comes from people who write it as part of their jobs. That means that feature additions & bug fixes in Linux will be largely those that matter to (say) Red Hat. This idea offers a way to get work I want done prioritized without needing to know how to do it myself. It also offers the possibility of software development midway between the start-up model that groups like YC and Kickstarter are pushing, and the no-money-involved-ever model. Surely somewhere between the two we might find something workable. > Also, when it comes to many projects, the organization that offers services around them has a negative incentive to contribute clear, quality code. A good point. I don't have an answer for that one.
Stwerner 13y ago
> Also, when it comes to many projects, the organization that offers services around them has a negative incentive to contribute clear, quality code. I'm probably being naive, but in my version of this idea, I was thinking that contributing well-written, tested, and documented code back upstream from the company's account would be a good way to have the work that's done contribute to the marketing. Part of the reason why I haven't moved past just talking about this idea is the possibility of it having a negative impact in terms of the original creators/maintainers, so I'm definitely interested in hearing more about this perspective on it.

yaur 13y ago

I believe this is called a RHEL subscription... in seriousness though this is a good idea and wouldn't be that hard to put together. You would monetize it by taking a cut of the spend and passing the rest on to the projects.

lukeholder 13y ago

is this what you are meaning? https://deps.io/ https://deps.io/

zimbatm 13y ago
This is a good start. Once you have all the customer's dependencies it becomes easier to offer value-added services like maintenance and feature development.

devinrhode2 13y ago

This is a lot like gittip and BountySource. Furthermore, a project maintainer could put on his README, that, for a certain recurring donation, you get some level of direct personal contact.