81–90 of 202 posts
Which relevant open source projects with a SaaS feel don't suffer from this? I.e. they are not open core and subject to some startup's agenda and risks. From the top of my mind, I remember Apache Airflow, which has a lot of open core competition right now.
Temporal. Kubernetes. Postgres. MySQL (MariaDB). Any all of Hashicorp tooling (Terraform, Consul, Vault etc).
What a sad page that merge request is. I feel bad for the developer who waited 4 months and got that as a response. :|
Earlier quoted context omitted.
Without putting blame on anyone, this does show a fundamental issue with the open core model. It is built on the premise that your "open" product will not be as good as possible, so you can still have the higher priced "enterprise" product. I think it's fair to point that out. Usually, you expect that developers want to create software that is "as good as possible". They may have a different idea what exactly "good"…
>show a fundamental issue with the open core model The alternative is the code doesnt exist. >Usually, you expect that developers When developers give away software for free I have no expections of them. If they fix a bug I consider that a favor not an obligation on their part. There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's madde…
One lesson from this is to not contribute a 'major feature' to an open source project without a signal that it would actually be accepted. Even if the feature doesn't conflict with enterprise/monetisation, the feature could just be against the goals of ideals of the maintainers, of whom the project is up to. Open source is not a mandate that the maintainers must accept every contribution. The author should consider w…
I'm honestly confused why anybody would waste their time working for free to improve an Open Core project. You're donating your labor to a private company to improve their product.
Other than that, there is no problem contributing to an open core project if it gets accepted. The community gets to benefit as well. On the other hand, a CLA in such a project is something you need to avoid by all means.
One lesson from this is to not contribute a 'major feature' to an open source project without a signal that it would actually be accepted. Even if the feature doesn't conflict with enterprise/monetisation, the feature could just be against the goals of ideals of the maintainers, of whom the project is up to. Open source is not a mandate that the maintainers must accept every contribution. The author should consider w…
Look at the timestamps. It’s months of complete silence, which is not a great sign from a saas. It was clear that the feature was popular. Another thing that annoys me to no end is locking threads because it’s “heated”. Just accept the grief and venting, people deserve it. It’s toxic positivity.
a project's issue tracker is first and foremost for the maintainers, any "community" that builds up there is secondary.
What this makes me wonder is whether there could be a way for GitHub or its equivalents to make the concept of “a fork by patching” a first-class concept. I’ve definitely done this for company-internal forks by trying to keep the changes as a clean list of linear commits that can be rebased as easily as possible, but it’s interesting to imagine what purpose-built tooling could do to facilitate maintaining such a patc…
Look at this PR and you’ll see a person who sacrificed their personal time to implement a highly requested feature.
The company sees a person they’ve never interacted with, send a large PR without asking, implementing a feature that undermines their Enterprise tier, for which they now need to allocate resource to get it reviewed, revised and integrated.
Earlier quoted context omitted.
>show a fundamental issue with the open core model The alternative is the code doesnt exist. >Usually, you expect that developers When developers give away software for free I have no expections of them. If they fix a bug I consider that a favor not an obligation on their part. There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's madde…
I personally think it's up to maintainers to set expectations. Many times maintainers will use open source projects on their resumes, advertise them on forums, give presentations, and then will be antagonistic towards even very friendly and objective issues and PRs. Even something as simple as "I built this for my own needs and have open sourced it for open knowledge and will only fix issues that further my own needs…
You were given something for free. That doesnt confer any rights, legal, moral or otherwise.
Drive by pull requests are not always welcome for any number of reasons which are the sole prerogative of the project maintainers who owe you nothing.
PRs are even worse when theyre big. If you do a large PR without informing anyone you should expect by default for it to be ignored.