5 ms·

How does HN feel about "open source but not open contributions"? I have several applications with source on github, but I'm not really interested in contributio

How does HN feel about "open source but not open contributions"? I have several applications with source on github, but I'm not really interested in contributions. I feel kind of bad about it, but they are "my" applications. The source is not secret and I don't mind people using it. That is why I publish it. Not to get help.

jeremy_wiebe 4y ago
I personally think that’s fine. There are still many benefits to an open source but no contributions model (such as others can see how you did things, it can be forked). Taking contributions requires effort on the part of the maintainer and I think it’s completely fair to want to open the code but not deal with that aspect of open source.
- docandrew 4y ago
  For smaller projects that don’t obviously have a lot of contributors, I think it is good etiquette to ask the maintainers ahead of time if they’re open to PR’s before submitting one, because like you said, it takes effort to accept patches.
  - jraph 4y ago
    Well, contributors should check if there are stated policies, but I think it's the author's duty to document that they don't take contributions and to disable the relevant features in the tools they use. A contribution is a nice thing from the contributor. As a contributor, I won't ask and then open a MR for a trivial contribution. It's too much trouble. I will ask for a bigger contribution to know if the author had related plans or their ways though. As an author, I do state that I'd rather not have medium/big contributions before we discussed about it in the project's CONTRIBUTING file.
    - dspillett 4y ago
      > but I think it's the author's duty to document that they don't take contributions It is polite to do so, and I'd make the effort, but I certainly wouldn't call it a duty at all. > and to disable the relevant features in the tools they use. That isn't always possible, and even when it is this does not stop contributions perhaps coming in by other means (email if you have an address publicly known, issue reports, …).
jraph 4y ago
It's fine. if it's not only source available but also open source, you are giving your users the four free software freedoms. That's already huge. They can study the thing. If someone wants something you don't provide, they have the right to make their own derivative. Possibly with open contributions. You can take from these forks if they are public and open source too (but you control what you take and how). If closed to contributions is the way you prefer writing your software, go for it! And you can always change your mind if needed. Taking contributions can be very fulfilling, satisfying, nice and everything, but it can also be tiring since it can require to be pedagogical, polite, possibly make compromises, argue, etc. Your call and thanks for releasing your software in any case :-)
msla 4y ago
There's no problem with it: As you say, it removes one barrier people have to making their software Open Source, which leads to more Open Source software in the world, which is good. It also allows strongly curated projects like SQLite to be Open Source, which is even better. Anyone who feels strongly about contributing to such a project is free to fork it.
- syncopate 4y ago
  sqlite's test suite is substantial and not open source, I doubt you could really fork it in a meaningful way
  - mcdonje 4y ago
    That raises a practical barrier to forking, but someone who is willing to get a testing suite up and running can fork the project and benefit from upstream changes on an ongoing basis.
gizmo686 4y ago
I have no principled objection to it, but it takes a very specific set of circumstances for it to make sense. You need enough funding to be able to work without outside help, an opinionated enough development philosophy that the cost of integrating external contributions exceeds the value they provide, and a reason to want to give away the source code. Plenty of companies have the first two, but consider the program they are developing a competitive advantage.
- dspillett 4y ago
  > but it takes a very specific set of circumstances for it to make sense. > funding Not everyone is coding for a commercial entity or otherwise monetising their projects, they might just be doing it for fun and want to share, but want to keep their version properly theirs. A key reason for this can be licensing, if the licence is not a very permissive one. If you have a project that is AGPL and you later want to change to MIT, or if you do decide to go commercial, then if all the code is yours that is easy: just do it. You can't revoke the earlier licence of course, so the last GPL release is effectively dual-licensed. If you have numerous other contributors then you may have issues with relicensing their contributions. They might not care if you are going from AGPL to something more permissive (though that might*, depending on ideology) but they are more likely to if there is money involved. Moving to a more restrictive license is often easier, but might still not be 100% plain sailing.
the_gipsy 4y ago
It's perfectly fine. It's only bad if it seems open to contributing but actually isn't. Having the source available and even a copyleft license does NOT imply open for contributions.
samwillis 4y ago
It's more than fine, it should be the default. The default absolutely should not be a social expectation to support and maintain something just because you made it available. The commitment to run an open source project is huge, it's time consuming and draining. Just putting the source code of something you built out there and saying "I built this, do what ever you want with it" is an incredibly generous thing to do and should always be encouraged.
- lliamander 4y ago
  > Just putting the source code of something you built out there and saying "I built this, do what ever you want with it" is an incredibly generous thing to do and should always be encouraged. Indeed, and originally that is what open source was all about! One of my pet peeves is the conflating of open source with some sort of communal development model. Open source certainly enables that model, but open source is much bigger than that. Furthermore, you need other things to make the communal model work well - specifically funding (like a foundation or other patronage funding model) to support development and community management.
chasil 4y ago
SQLite is used by flight systems on the Airbus a350. It is the only major database that has obtained DO-178B certification, allowing it to operate legally in this avionics environment and role. Relaxing the strict controls upon it, and allowing contributions that do not pass the tests (in th3) will remove newer versions from avionics applications. There are some people who are actively trying to fork, which means precisely the above. I read at some point that Airbus has a software support agreement in place for SQLite that expires in 2050. https://sqlite.org/th3.html#history https://sqlite.org/th3.html#history
- SubjectToChange 4y ago
  Note well, “Flight systems” and “avionics” are different things. Standards like DO-178 require all airborne software to be assigned a DAL (Design Assurance Level), i.e. simply being part of a “DO-178C certified system” doesn’t imply being safety critical.
huijzer 4y ago
I think contributions can definitely be good if they are going into the project’s intended direction. Issues containing, especially containing "why don’t you just", on the other hand turn me off from open source development.
dzonga 4y ago
open but not open to contributions - should be the default. look at the clusterfuck known as the javascript ecosystem or linux desktop system as another poster alluded to earlier. quality is automatically improved by having few people contributing - that have a singular goal.
smashah 4y ago
There's no need to ask how others feel about your code. You don't need to pass some purity test to share your code in a way you're comfortable with. You don't need to live up to some zeitgeist idea of what OSS is or follow a template. Blaze your trail as far and as wide as you want.

jeremy_wiebe 4y ago

I personally think that’s fine. There are still many benefits to an open source but no contributions model (such as others can see how you did things, it can be forked). Taking contributions requires effort on the part of the maintainer and I think it’s completely fair to want to open the code but not deal with that aspect of open source.

docandrew 4y ago
For smaller projects that don’t obviously have a lot of contributors, I think it is good etiquette to ask the maintainers ahead of time if they’re open to PR’s before submitting one, because like you said, it takes effort to accept patches.
- jraph 4y ago
  Well, contributors should check if there are stated policies, but I think it's the author's duty to document that they don't take contributions and to disable the relevant features in the tools they use. A contribution is a nice thing from the contributor. As a contributor, I won't ask and then open a MR for a trivial contribution. It's too much trouble. I will ask for a bigger contribution to know if the author had related plans or their ways though. As an author, I do state that I'd rather not have medium/big contributions before we discussed about it in the project's CONTRIBUTING file.
  - dspillett 4y ago
    > but I think it's the author's duty to document that they don't take contributions It is polite to do so, and I'd make the effort, but I certainly wouldn't call it a duty at all. > and to disable the relevant features in the tools they use. That isn't always possible, and even when it is this does not stop contributions perhaps coming in by other means (email if you have an address publicly known, issue reports, …).

jraph 4y ago

It's fine. if it's not only source available but also open source, you are giving your users the four free software freedoms. That's already huge. They can study the thing. If someone wants something you don't provide, they have the right to make their own derivative. Possibly with open contributions. You can take from these forks if they are public and open source too (but you control what you take and how). If closed to contributions is the way you prefer writing your software, go for it! And you can always change your mind if needed. Taking contributions can be very fulfilling, satisfying, nice and everything, but it can also be tiring since it can require to be pedagogical, polite, possibly make compromises, argue, etc. Your call and thanks for releasing your software in any case :-)

msla 4y ago

There's no problem with it: As you say, it removes one barrier people have to making their software Open Source, which leads to more Open Source software in the world, which is good. It also allows strongly curated projects like SQLite to be Open Source, which is even better. Anyone who feels strongly about contributing to such a project is free to fork it.

syncopate 4y ago
sqlite's test suite is substantial and not open source, I doubt you could really fork it in a meaningful way
- mcdonje 4y ago
  That raises a practical barrier to forking, but someone who is willing to get a testing suite up and running can fork the project and benefit from upstream changes on an ongoing basis.

gizmo686 4y ago

I have no principled objection to it, but it takes a very specific set of circumstances for it to make sense. You need enough funding to be able to work without outside help, an opinionated enough development philosophy that the cost of integrating external contributions exceeds the value they provide, and a reason to want to give away the source code. Plenty of companies have the first two, but consider the program they are developing a competitive advantage.

dspillett 4y ago
> but it takes a very specific set of circumstances for it to make sense. > funding Not everyone is coding for a commercial entity or otherwise monetising their projects, they might just be doing it for fun and want to share, but want to keep their version properly theirs. A key reason for this can be licensing, if the licence is not a very permissive one. If you have a project that is AGPL and you later want to change to MIT, or if you do decide to go commercial, then if all the code is yours that is easy: just do it. You can't revoke the earlier licence of course, so the last GPL release is effectively dual-licensed. If you have numerous other contributors then you may have issues with relicensing their contributions. They might not care if you are going from AGPL to something more permissive (though that might*, depending on ideology) but they are more likely to if there is money involved. Moving to a more restrictive license is often easier, but might still not be 100% plain sailing.

the_gipsy 4y ago

It's perfectly fine. It's only bad if it seems open to contributing but actually isn't. Having the source available and even a copyleft license does NOT imply open for contributions.

samwillis 4y ago

It's more than fine, it should be the default. The default absolutely should not be a social expectation to support and maintain something just because you made it available. The commitment to run an open source project is huge, it's time consuming and draining. Just putting the source code of something you built out there and saying "I built this, do what ever you want with it" is an incredibly generous thing to do and should always be encouraged.

lliamander 4y ago
> Just putting the source code of something you built out there and saying "I built this, do what ever you want with it" is an incredibly generous thing to do and should always be encouraged. Indeed, and originally that is what open source was all about! One of my pet peeves is the conflating of open source with some sort of communal development model. Open source certainly enables that model, but open source is much bigger than that. Furthermore, you need other things to make the communal model work well - specifically funding (like a foundation or other patronage funding model) to support development and community management.

chasil 4y ago

SQLite is used by flight systems on the Airbus a350. It is the only major database that has obtained DO-178B certification, allowing it to operate legally in this avionics environment and role. Relaxing the strict controls upon it, and allowing contributions that do not pass the tests (in th3) will remove newer versions from avionics applications. There are some people who are actively trying to fork, which means precisely the above. I read at some point that Airbus has a software support agreement in place for SQLite that expires in 2050. https://sqlite.org/th3.html#history https://sqlite.org/th3.html#history

SubjectToChange 4y ago
Note well, “Flight systems” and “avionics” are different things. Standards like DO-178 require all airborne software to be assigned a DAL (Design Assurance Level), i.e. simply being part of a “DO-178C certified system” doesn’t imply being safety critical.

huijzer 4y ago

I think contributions can definitely be good if they are going into the project’s intended direction. Issues containing, especially containing "why don’t you just", on the other hand turn me off from open source development.

dzonga 4y ago

open but not open to contributions - should be the default. look at the clusterfuck known as the javascript ecosystem or linux desktop system as another poster alluded to earlier. quality is automatically improved by having few people contributing - that have a singular goal.

smashah 4y ago

There's no need to ask how others feel about your code. You don't need to pass some purity test to share your code in a way you're comfortable with. You don't need to live up to some zeitgeist idea of what OSS is or follow a template. Blaze your trail as far and as wide as you want.