Hacker News Reader

Comment by account42 | Hacker News Reader

These are great things to do if you want to buld a community around a project (which does help keep it going). But it's also OK to just build what you want and publish that and then maybe accept contributions under whatever terms you feel like. Community management really is an entirely different skillset from software developement and I wouldn't want anyone to be discouraged from open sourcing their software if they are not a "people person" and don't want to deal with all that. Just sharing your work already makes the world better and you are NOT required to do anything more than that.

View on HN

Back in the day, Open Source projects thrived on the enthusiasm of creators who didn't view software development as a means to make money. Instead, they saw it as an opportunity to build a community and create superior products through collaboration.

However, the landscape has shifted. When an Open Source project becomes successful today, creators often transition the original product into a proprietary version with added features and support, available only through paid access. This practice undermines the original Open Source project, and usually end off killing the original project.

That's fairly rare, when you consider the massive amount of open source. There's also many good examples of open core projects.

But the risk is always lurking. I guess this holds of some from contributing to open source projects, fearing this fate.

This is extremely easy to avoid in practice, just don't contribute to projects that make you sign a CLA.

Back in the day, most users were more technical (TFA is about a regular user using DOS, just as an example) so the ratio of contributors to users was higher

When a FOSS project gets big now, users show up in the issue trackers expecting the kind of support they are accustomed to from companies. They do not have the desire or ability to contribute.

Maintainers then get overwhelmed unless they have some way to support these users. Either they can raise money somehow in order to hire help -- like adding a proprietary version -- or get burned out and complain they didn't get enough donations.

This is just reality. We don't live in RMS's MIT computer lab where he set all the passwords to empty because computers should be free and everyone (every MIT student) is capable of writing software and thus should be able to.

Regular people just want to use the software and they will always outnumber contributors from now on.

> they saw it as an opportunity to build a community

Many small open source projects still operate this way and their community consists a small number of people who have fun hacking on a project together after work.

But as projects grow some of them acquiesce to end-user expectations and slowly turn into "organizations".

They have schedules and regular releases, commit to timely triaging of bug reports, provide forums for end-user support, publish status updates, respond to feature requests, write documentation, have a slick website with a nice logo, form committees and sub-committees to make decisions, adopt codes of conduct to try to deal with the jerks who invariably show up, file the paperwork necessary to deal with big donations, etc -- all the "necessary bureaucracy" that comes with being a large, reputable organization.

At that point you've basically added back all the unfun parts of working and turned it into a second job, so why not get paid?

Much of the money that flows into OSS foundations goes to director salaries and unproductive projects.

Some developers get paid by companies, but they usually come late to the project when most fundamental work has been done already (this depends on the project, Linux for example might be an exception in that sponsorship has started comparatively early).

Most developers who have done fundamental work before the commercialization of OSS get nothing. The beneficiaries of the whole thing are developers who are now 25-30, work for FAANG and take over existing projects while not doing really much.

BTW, the real jerks are often wolves in sheep's clothing who do excessively well in the bureaucratic apparatus.

People also just get wildly entitled.

I stay anonymous, but I built some software that people use for scientific analysis. I give it away; I don't put it on my resume; the only thing I've gotten from it is it makes me a bit happy that maybe I've saved someone else hundreds of hours of work. There's also some subtle numerical properties that take real work to get right.

(Not all, but some) people demand support, features, or bugfixes; and on their schedule. Or docs, or a prettier site, or blah blah blah, and every second of this takes away time from my real job, my now elderly dog, hobbies, etc. Recently there was a wave of it from some library weirdness on m-chip macs, which I don't even own. And they're guaranteed to get very pissy when I tell them I don't care at all (and, in several cases, if they want me to care they can start by shipping me a new mac and I'll think about it). I honestly mostly just delete the emails anymore because reading them makes me wonder why I'm wasting time on a computer.

As I mentioned, sharing makes me happy and feel like I gave a bit back, but all the shit that comes after that is ugh.

I think this a consequence of the open-source marketing strategy of big tech companies and commercialization the parent talked about. When developers use open-source, most of the time maintainers are paid and it’s part of their job, and of the parent company’s strategy.

In this landscape it’s unfortunate but I think one way to avoid this especially if published on GitHub is to be upfront in the README that this is a hobby project with no support, only to be used professionally at your own risks (buried in the license is not enough). Otherwise if projects are presented too similarly to professional ones it’s fair to expect developers to be confused, it’s just unfortunate to what GitHub has turned and that the burden is on hobbyist maintainers to differentiate now but that’s where we are.

And also unfortunate is the practice of resume building by publishing professional looking projects on GitHub that adds to the confusion.

I like the idea of a standardized way of conveying where the project exists on a spectrum of personal hobby to foundation. I'd personally imagine four levels:

Level 0: This code meets (met?) my personal needs. I'm pleased if you find it useful but do not expect a response to suggestions or bug reports.

Level 1: This tool has a solo maintainer. I'll do my best to incorporate suggestions that fit my vision and address bug reports with reproduction steps when I have free time.

Level 2: This project is maintained by a handful of like-minded contributors. Besides suggestions and bug reports, if you're interested in contributing, please join our discord/element/forum/listserv.

Level 3: This project is maintained by an organization. Before submitting a bug report, please read our wiki.

This is a late update but the site and docs make it extremely clear it's a level 0. ala here's a thing that may help you; I no longer use it either personally or professionally so adjust your expectations accordingly.

This has not dissuaded people from complaining.

Thanks for your contributions!

Deleting inappropriate requests is totally reasonable, but one alternative could be a template letter, if you don't happen to have one already. When I receive inappropriate demands for my time I find it hard to muster the sympathy necessary to write a kind and patient message explaining that their priorities are not my priorities. It's much easier if I have something ready to go.

Just building what you want and publishing it doesn't work anymore. Look at the countless projects wilting away because the "community" actively ignores them and the huge volume of content doesn't target those projects anymore. No tutorials, no guides, no evangelists, no Github stars and forks, no Twitter promoters, no fancy shmancy *.io domain and interactive Docs with oodles of integrations with everything under the sun means that your project will languish in ignored obscurity. Two big-ish projects getting that treatment that I've personally witnessed happening in slow-motion over many years: Tornado and Knockout.js.

Languishing in ignored obscurity is fine for the stuff I open source. There's no expectations but it's not hidden from anyone either.

I think there's a difference of opinion here about what it means for it to "work". The point I infer from the parent comment (which I happen to agree with) is that measuring success or failure in terms of the community is orthogonal to open source. If what you want is a successful community, then it makes sense to base your decision on whether to be open source or not on that, but failing to build a long-lasting community isn't a failure of open source itself but at using it as a tool to try to achieve a specific goal, and not everyone doing open source shares that goal.

As an aside, I think it's worth noting that most attempts to build long-lasting, vibrant communities for software fail, regardless of whether they're open source or not. Open source might not have a high success rate of community-building, but neither does proprietary software (or whatever middle ground you consider to be in the space between those terms, like "open core" or "source available"). If what you care about most is building a large community, the more effective choice probably depends on a lot of factors specific to what you're building and what else is going on at the time you're trying than something as simple as "always be open source" or "always be proprietary".

Reply on news.ycombinator.com