3 ms·

It looks like DevFlight's focus is on identifying active revenue streams for maintainers, based on whatever aspects the maintainer is flexible in commercializin

by cosmie 8y ago

It looks like DevFlight's focus is on identifying active revenue streams for maintainers, based on whatever aspects the maintainer is flexible in commercializing (priority support, feature requests, etc). That's an awesome way to help create revenue without splitting the maintainers' attention between sales and the project. A tangentially related idea I've had for helping fund OSS is offering a service that generates a passive revenue stream for projects via merchandise/swag sales. Essentially, the project gives you a license to use their IP (logos, slogans, trademarks, etc) for use on merchandise, then you operate an online store that provides branded merchandise for the project and provide a royalty back to the project based on a percentage of profit. It can be as passive as the maintainers want, other than (potentially) creating a CNAME to the online store and adding a link to their website. All of the operational aspects of running an online store are completely abstracted from the maintainer, and they just get a periodic royalty payment. Or as active as they want, if the maintainers want to take part in designing (or approving) the merchandise, promoting it, etc. The passive version also works perfectly for 501(c)3 non-profits, as the royalty payments would qualify as an exception to the "unrelated business income" rules and be considered tax-exempt revenue[1]. The size of the revenue stream is pretty proportional to the popularity of your project, so hidden projects with lots of indirect users would likely only generate a modest amount of revenue. But projects with a lot of direct users/site traffic or an engaged/passionate community would likely be a hit, from individuals buying stuff directly to manager's buying swag for their team. If there are any project maintainers that would be interested in exploring the idea, please reach out (email in profile)! I can cover the execution side of things, and would love the chance to validate the model. [1] Based on a naive reading of https://www.irs.gov/pub/irs-pdf/p598.pdf https://www.irs.gov/pub/irs-pdf/p598.pdf

zapita 8y ago
I also like that DevFlight works with individual maintainers, rather than with projects. Many prolific maintainers work with several projects. They may not have created any of those projects, and they may not run them either. When the spotlight is on the project (and by extension the founders of "top dogs" of that project), those valuable maintainers get ignored. I'm glad DevFlight is focusing on the individual.
- cosmie 8y ago
  I don't disagree that finding ways for prolific open source contributors to be able to monetize their expertise is incredibly valuable, but I'm not sure if that's actually DevFlight's focus. Their website copy focuses on "the maintainer's" project, and DevFlight's comments on this post repeatedly reference leveraging any community channels the maintainer created (such as social media and Slack) for outreach. As well, the example list of projects they listed above has a presumption of authority/control over the project or else they don't make as much sense - you can't guarantee things like project stability or prioritize features without having some presumption of authority over the project to back it. While DevFlight is focusing on the individual, from what I can tell it's specifically on individuals that are project maintainers, and not simply prolific contributors. From a corporate standpoint, those are two vastly different sales pitches. If the maintainer of the project commits to prioritizing feature requests or stability of the project, then they have the actual authority/capacity to follow through on that commitment. A prolific contributor might have the expertise and familiarity with the project to make those commitments, but if the maintainers have other ideas, the contributor would have no resolution other than to fork the project to maintain their commitment. Then the company is operating off of a custom fork of the project, maintained by a single person and not as battle tested as the official project, which may or may not have to deviate further away from the official project over time depending on what the contributor committed to vs. where the official project is going. Companies hire third parties to customize, integrate, and support software all the time. And a prolific contributor to a project is a really good individual to choose for that type of work. The conversion rate for cold selling those services via outbound lead generation, without the weight of someone who can speak authoritatively on behalf of the project, will be significantly lower though. Hopefully Victor or Tony can chime in and provide some clarification on who their target audience is. :)
  - tmastro 8y ago
    Great question. At this point, we’re focused on partnering with core maintainers of a project. As you’ve stated, these are the individuals who have control over what gets implemented in a project and ensuring project stability. However, we are also exploring ways to get expert contributors involved in the future.

by cosmie 8y ago

zapita 8y ago

I also like that DevFlight works with individual maintainers, rather than with projects. Many prolific maintainers work with several projects. They may not have created any of those projects, and they may not run them either. When the spotlight is on the project (and by extension the founders of "top dogs" of that project), those valuable maintainers get ignored. I'm glad DevFlight is focusing on the individual.

cosmie 8y ago
I don't disagree that finding ways for prolific open source contributors to be able to monetize their expertise is incredibly valuable, but I'm not sure if that's actually DevFlight's focus. Their website copy focuses on "the maintainer's" project, and DevFlight's comments on this post repeatedly reference leveraging any community channels the maintainer created (such as social media and Slack) for outreach. As well, the example list of projects they listed above has a presumption of authority/control over the project or else they don't make as much sense - you can't guarantee things like project stability or prioritize features without having some presumption of authority over the project to back it. While DevFlight is focusing on the individual, from what I can tell it's specifically on individuals that are project maintainers, and not simply prolific contributors. From a corporate standpoint, those are two vastly different sales pitches. If the maintainer of the project commits to prioritizing feature requests or stability of the project, then they have the actual authority/capacity to follow through on that commitment. A prolific contributor might have the expertise and familiarity with the project to make those commitments, but if the maintainers have other ideas, the contributor would have no resolution other than to fork the project to maintain their commitment. Then the company is operating off of a custom fork of the project, maintained by a single person and not as battle tested as the official project, which may or may not have to deviate further away from the official project over time depending on what the contributor committed to vs. where the official project is going. Companies hire third parties to customize, integrate, and support software all the time. And a prolific contributor to a project is a really good individual to choose for that type of work. The conversion rate for cold selling those services via outbound lead generation, without the weight of someone who can speak authoritatively on behalf of the project, will be significantly lower though. Hopefully Victor or Tony can chime in and provide some clarification on who their target audience is. :)
- tmastro 8y ago
  Great question. At this point, we’re focused on partnering with core maintainers of a project. As you’ve stated, these are the individuals who have control over what gets implemented in a project and ensuring project stability. However, we are also exploring ways to get expert contributors involved in the future.