3 ms·

It doesn't work if the project hasn't had any new issues in a while. There is no incentive to be part of the OpenCollective if the project is completed and has

It doesn't work if the project hasn't had any new issues in a while. There is no incentive to be part of the OpenCollective if the project is completed and has no bugs. I've been struggling with this issue with my project. It's a completed project, no scope creep, no bugs, just occasional update once every 6 months or so. The docs are complete and detailed so nobody needs extra help; no one will pay for support At the same time, I know for a fact that if the project was buggy or had gaps in the documentation, nobody would use it; they would use an alternative solution from a big corporation. The level of competition is so intense that there is no room for profit, no room for missing documentation and no room for bugs on my end. Competing products are backed by a big name brand tech corporations; so they can have bugs and gaps in the documentation and users will forgive them. Branding is extremely powerful. Once people trust a brand name, they will ignore reality. If you don't have a brand name, you need to be 10x better to be perceived as the same quality.

bruce511 4y ago
Perhaps it would be helpful to articulate what you feel you are missing? (I'm presuming money, but I don't want to put words in your mouth.) It sounds to me like you have a solid project, and some number of users. With good docs. Which is great (we'll done.) I'm assuming you want to monetize it? That seems to be the logical next step. Alas I'm not going to be very comforting with the next bit. A) the time to think about monetization is when you start the project, not when it's done. Obviously a lot of projects get done for reasons other than money, and when you started you may have had other reasons. That's fine. But monetizing after-the-fact is a very difficult, dare I say "unsolved" problem. B) this is going to sting, but most successful money-earning products have nothing to do with the code, beyond that it exists. A "business" requires more than "product" - a lot more. Marketing, sales, revenue, administration and so on. All of this is expensive, hence the need to have a business plan (ie, how does this thing make money?) before you start. As developers we have a code-first mindset. But we try and compete with companies that have a business-first mindset. Companies are winning. The fact that your project is complete, that it is solid is fantastic. Well done for that. However turning it into a business may be impossible, or expensive. That's OK. Celebrate what is is, don't pine for what isn't. If nothing else you've learned the difference between a code project, and a business, and if you internalise that then you will have gained something of high value.
- loopgh 4y ago
  I feel that you and the GP are mostly in violent agreement. GP just stated his experiences, which are not obvious for one's first large project. What is missing is recognition for those small projects without marketing or branding that are better and more bug-free than corporate projects. Money is not needed, just recognition.
quickthrower2 4y ago
Which makes sense in a way because part of the brand is “we’ll be around in 2033 to support this”. And “need help? see myriad answers on stackoverflow” and so on.
- loopgh 4y ago
  Projects from big companies disappear faster than, say, Vim and many other similar projects.
  - quickthrower2 4y ago
    Vim is definitely a brand though. It is more than that, it has cult following. Big companies known for abandoning projects have a bad brand in that regard (although their brand might be good in other areas).
pie_flavor 4y ago
I'm not saying that Fody's model is superior to selling retail software, if what you are in the business of doing is selling retail software. I'm saying that it's superior to giving up on open source monetization if what you're in the business of doing is open source.
- ahepp 4y ago
  Fody says they have an “honesty system” and expect all users to pay, even if they’re not raising issues or PRs. That’s despite the fact that the code is MIT licensed. How is that a more ethical, straightforward, or profitable business model than just GPLing the project and offering proprietary licensing? Releasing code under a permissive license, then calling people dishonest when they use it according to the license but not the authors’ desires, seems silly and inefficient.

bruce511 4y ago

Perhaps it would be helpful to articulate what you feel you are missing? (I'm presuming money, but I don't want to put words in your mouth.) It sounds to me like you have a solid project, and some number of users. With good docs. Which is great (we'll done.) I'm assuming you want to monetize it? That seems to be the logical next step. Alas I'm not going to be very comforting with the next bit. A) the time to think about monetization is when you start the project, not when it's done. Obviously a lot of projects get done for reasons other than money, and when you started you may have had other reasons. That's fine. But monetizing after-the-fact is a very difficult, dare I say "unsolved" problem. B) this is going to sting, but most successful money-earning products have nothing to do with the code, beyond that it exists. A "business" requires more than "product" - a lot more. Marketing, sales, revenue, administration and so on. All of this is expensive, hence the need to have a business plan (ie, how does this thing make money?) before you start. As developers we have a code-first mindset. But we try and compete with companies that have a business-first mindset. Companies are winning. The fact that your project is complete, that it is solid is fantastic. Well done for that. However turning it into a business may be impossible, or expensive. That's OK. Celebrate what is is, don't pine for what isn't. If nothing else you've learned the difference between a code project, and a business, and if you internalise that then you will have gained something of high value.

loopgh 4y ago
I feel that you and the GP are mostly in violent agreement. GP just stated his experiences, which are not obvious for one's first large project. What is missing is recognition for those small projects without marketing or branding that are better and more bug-free than corporate projects. Money is not needed, just recognition.

quickthrower2 4y ago

Which makes sense in a way because part of the brand is “we’ll be around in 2033 to support this”. And “need help? see myriad answers on stackoverflow” and so on.

loopgh 4y ago
Projects from big companies disappear faster than, say, Vim and many other similar projects.
- quickthrower2 4y ago
  Vim is definitely a brand though. It is more than that, it has cult following. Big companies known for abandoning projects have a bad brand in that regard (although their brand might be good in other areas).

pie_flavor 4y ago

I'm not saying that Fody's model is superior to selling retail software, if what you are in the business of doing is selling retail software. I'm saying that it's superior to giving up on open source monetization if what you're in the business of doing is open source.

ahepp 4y ago
Fody says they have an “honesty system” and expect all users to pay, even if they’re not raising issues or PRs. That’s despite the fact that the code is MIT licensed. How is that a more ethical, straightforward, or profitable business model than just GPLing the project and offering proprietary licensing? Releasing code under a permissive license, then calling people dishonest when they use it according to the license but not the authors’ desires, seems silly and inefficient.