4 ms·

probably one of the dark horse reasons for success is its "open source but not open contributions" model and strong personal leadership from Richard. that clari

by swyx 4y ago

probably one of the dark horse reasons for success is its "open source but not open contributions" model and strong personal leadership from Richard. that clarity of vision and very personal stewardship of the project (listen to him talk with pride about SQLite's aircraft certifications.. not a joke) is something very few open source projects ever have

rlv-dan 4y ago
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.
nindalf 4y ago
> open source but not open contributions I never understood this. Does it mean other open source projects are "open contributions" and anyone can just go ahead and commit to master? No. Literally every project requires you to have a discussion with the maintainer(s) before your contribution can be merged in. In larger projects, it requires going through a change process.
- Tomte 4y ago
  > Literally every project requires you to have a discussion with the maintainer(s) before your contribution can be merged in. But they can be merged in. SQLite clearly says "not interested in your code". At all. It's not like they are unfriendly. They will happily discuss things in detail with you, but you can publish your own extension. SQLite proper is developed by Mr. Hipps and his friends/employees. A very sensible model, if you ask me.
  - metaltyphoon 4y ago
    What amazes me is how people are insensitive about other choices.
- mort96 4y ago
  With almost any other project, I can take the source code, make some change, and then propose that the upstream project incorporates my change. If the upstream project thinks my code is good, they will incorporate it as-is. With SQLite, that's just not a process. There is no process whereby code written by anyone other than the SQLite maintainers enters the git repository.
MuffinFlavored 4y ago
How do the people who work on/maintain this full time "afford" to do so? Is it their day job?
- Quekid5 4y ago
  I believe so. See https://sqlite.org/consortium.html https://sqlite.org/consortium.html for how they're funded. Plus of course you can pay for SQLite itself with various levels of support, etc. See: https://sqlite.org/prosupport.html https://sqlite.org/prosupport.html
- fukawi2 4y ago
  My company pays the sqlite team a significant amount annually for a support contract. (Without going into too much detail, the primary database for our application is an approximately 2TB sqlite database - no, that's not a typo).
MPlus88 4y ago
[flagged]
- zffr 4y ago
  SQLite is monetized: https://www.sqlite.org/prosupport.html https://www.sqlite.org/prosupport.html
sph 4y ago
I didn't know that, and I appreciate SQLite much more now. I love open source, but I am a huge proponent of strong leadership and vision as the best model to create outstanding software. You need a BDFL, a Torvalds saying "no," a Jobs saying "this is what I want and I will not compromise." Too many open sources project adopt the anything goes model and remain mediocre. The Linux desktop is the most visible example of this. Sadly 99% of open source projects tend to suffer from this problem, and add features just because someone took the time to write a PR. This is the only reason, IMO, why open source software is often a second rate alternative to commercial offerings: if the source is closed, it is harder for a product's vision to get diluted and lost over time. SQLite shows it is possible to create incredible open source software true to its original vision.
rr888 4y ago
I can't find the source but I remember reading about BSD how they hated taking on other people's code, in the rare cases they did they "pissed on it until it smelt like ours" which stuck in my mind as one of the greatest quotes ever.

by swyx 4y ago

rlv-dan 4y ago

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.

nindalf 4y ago

> open source but not open contributions I never understood this. Does it mean other open source projects are "open contributions" and anyone can just go ahead and commit to master? No. Literally every project requires you to have a discussion with the maintainer(s) before your contribution can be merged in. In larger projects, it requires going through a change process.

Tomte 4y ago
> Literally every project requires you to have a discussion with the maintainer(s) before your contribution can be merged in. But they can be merged in. SQLite clearly says "not interested in your code". At all. It's not like they are unfriendly. They will happily discuss things in detail with you, but you can publish your own extension. SQLite proper is developed by Mr. Hipps and his friends/employees. A very sensible model, if you ask me.
- metaltyphoon 4y ago
  What amazes me is how people are insensitive about other choices.
mort96 4y ago
With almost any other project, I can take the source code, make some change, and then propose that the upstream project incorporates my change. If the upstream project thinks my code is good, they will incorporate it as-is. With SQLite, that's just not a process. There is no process whereby code written by anyone other than the SQLite maintainers enters the git repository.

MuffinFlavored 4y ago

How do the people who work on/maintain this full time "afford" to do so? Is it their day job?

Quekid5 4y ago
I believe so. See https://sqlite.org/consortium.html https://sqlite.org/consortium.html for how they're funded. Plus of course you can pay for SQLite itself with various levels of support, etc. See: https://sqlite.org/prosupport.html https://sqlite.org/prosupport.html
fukawi2 4y ago
My company pays the sqlite team a significant amount annually for a support contract. (Without going into too much detail, the primary database for our application is an approximately 2TB sqlite database - no, that's not a typo).

MPlus88 4y ago

[flagged]

zffr 4y ago
SQLite is monetized: https://www.sqlite.org/prosupport.html https://www.sqlite.org/prosupport.html

sph 4y ago

I didn't know that, and I appreciate SQLite much more now. I love open source, but I am a huge proponent of strong leadership and vision as the best model to create outstanding software. You need a BDFL, a Torvalds saying "no," a Jobs saying "this is what I want and I will not compromise." Too many open sources project adopt the anything goes model and remain mediocre. The Linux desktop is the most visible example of this. Sadly 99% of open source projects tend to suffer from this problem, and add features just because someone took the time to write a PR. This is the only reason, IMO, why open source software is often a second rate alternative to commercial offerings: if the source is closed, it is harder for a product's vision to get diluted and lost over time. SQLite shows it is possible to create incredible open source software true to its original vision.

rr888 4y ago

I can't find the source but I remember reading about BSD how they hated taking on other people's code, in the rare cases they did they "pissed on it until it smelt like ours" which stuck in my mind as one of the greatest quotes ever.