Live data from Hacker News

Give away your code, but never your time

wgross.net

101–110 of 228 posts

Re: Give away your code, but never your time

#101

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?

err ICO?

Re: Give away your code, but never your time

#102

What 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…

That's the right approach. The question is whether you can keep enforcing that - sticking to the product roadmap and release plan - if/when a large software company becomes a "customer" of your open source project. That's when it requires a tremendous amount of discipline to stick to this. But the right approach.

Re: Give away your code, but never your time

#103
Yep, that agrees with one rule I've found very helpful in my Sidekiq project:

All 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

#104
The open source community defies definition. It's a diverse multitude of people with different motivations. This will ensure its survival even under challenging circumstances.

There 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

#105

Earlier 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.

There arent many places that would allow you to contribute in your work time. Stop these guesses about the guy and quit attacking him for those stuff you invented.

Re: Give away your code, but never your time

#106

Glad 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…

If they sent patches they already did the work. They might have maintained the patch against mainstream, but they contributed back instead. Your friend was under no obligation to merge. I cant see any free labour here.

Re: Give away your code, but never your time

#107
post #13

Color 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…

Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.

Re: Give away your code, but never your time

#109
post #72

As 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…

You're likely going to be shut down by GitHub. They have a special section in their ToS that prohibits advertising.

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

#110
post #13

Color 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…

> One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.

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.

Post reply on HN