Here are a few ideas off the top of my head for a purely open source (non-commercial) project: * custom features * prioritization * training * enterprise support * sponsorships * invites to free conferences and swag * t-shirts and swag sales * commercial software integrations/partnerships * brand sponsorship/inclusion on docs/websites/etc. * professionally managed and scalable hosting What did I miss?
Give away your code, but never your time
101–110 of 228 posts
Re: Give away your code, but never your time
#102What works for me is locking down the application behind a plan. Users can submit whatever feedback, bugs, suggestions, enhancements, and wishlists they want. These contributions are important, but they won't change the roadmap. This only works when an open source application becomes ubiquitous or nearly ubiquitous and the users want it everywhere. Popularity and consumption rates are irrelevant to whether this works…
Re: Give away your code, but never your time
#103All free/OSS work/discussion is done in public.
Never private email, never Slack. Always open an issue. Security issues are the exception here. No one should get to monopolize my time without paying.
Re: Give away your code, but never your time
#104There is a risk, maybe significant, of the generational hand off. A lot of folks who built this rich legacy were academics and pioneers motivated by ideology. Software has moved on from early pioneers motivated by liberty and freedom issues to being subsumed by establishment interests.
At the moment there is also widespread cynicism about ideology in general and a lot of open source is increasingly developed by corporate interests. This could have repercussions for the 'nature' of open source as institutions and a connection to individuals beyond their identity as 'users' has not really been built.
Re: Give away your code, but never your time
#105Earlier quoted context omitted.
Your company almost certainly makes use of multiple pieces of open source software. What do you do when you need a feature that doesn't yet exist in one of them?
He probably opens an issue and then complains why the project maintainers don’t give it priority. He is too busy to do privileged OSS work.
Re: Give away your code, but never your time
#106Glad to see other ideas and operating models being proposed and tried. Most of us live in countries where you need money to pay rent and buy food. Unless you're already wealthy, that means you need to work (trade time for money) or find a way to trade time for an ownership stake that will, you hope, generate income (and in the process that stake becomes itself more valuable). A buddy of mine in a maintainer for a pop…
Re: Give away your code, but never your time
#107Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay. The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them. Most maintainers err on the side of controlling too much. Which makes them into bottlenecks. One or two good PRs is enough for me to g…
Re: Give away your code, but never your time
#108Re: Give away your code, but never your time
#109As much as I agree with the sentiment behind this post, I disagree with the implementation. The nature of open source code is collaboration. Paying for collaboration seems like it would hinder progress altogether and possibly direct the project into a direction that is not suitable for the poor majority not paying. One more thing that bothers me is that money for maintenance should not come from developers. This is l…
https://help.github.com/articles/github-terms-of-service/#k-...
> Short version: We do not generally prohibit use of GitHub for advertising. However, we expect our users to follow certain limitations, so GitHub does not become a spam haven. No one wants that.
Re: Give away your code, but never your time
#110Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay. The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them. Most maintainers err on the side of controlling too much. Which makes them into bottlenecks. One or two good PRs is enough for me to g…
In addition, I find it's helpful to identify the really keen contributors and ask them privately see if they want to take on more responsibilities.