12 ms·

> The few core developers they have do not work with modern tools like git and collaboration tools like Github, and don’t accept contributions, although they ma

by diffxx 4y ago

> The few core developers they have do not work with modern tools like git and collaboration tools like Github, and don’t accept contributions, although they may or may not accept your suggestion for a new feature request. The funny thing about this comment is that SQLite is as close to the gold standard of software quality that we have in the open source world. SQLite is the only program that I've ever used that reliably gets better with every release and never regresses. Could it be that this is precisely because they don't use "modern tools" and accept outside contributions?

tingletech 4y ago
I think you are right. Their rational for not using git seems reasonable to me https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html
deleted 4y ago
[deleted]
Ar-Curunir 4y ago
You're conflating two different arguments: not using modern tools, and not accepting outside contributions. It's certainly possible that limiting contributions to a set of trusted contributors helps things move smoothly. However it's not clear at all that using old tools has the same effect.
- notRobot 4y ago
  They don't use old tools, they use different tools. Git development started in 2005, Fossil development started in 2006, they'ré equally modern, and largely do the same things, just in different ways.
  - diffxx 4y ago
    Also, Fossil is essentially implemented _in_ SQLite. Fossil is used to develop SQLite which is used to implement Fossil. It's a virtuous cycle. For the SQLite project, using Fossil is obviously superior to git. This doesn't mean that arbitrary projects should use Fossil over git.
    - ThunderSizzle 4y ago
      The opposite can be said though, but git arbitrarily won over a bunch of other DVCS systems (another e.g. hg), mainly because of bandwagon and marketing.
- ok_dad 4y ago
  > old tools I have some of my great-grandpa's carpentry tools, and I use them often. I guess I should go out and replace perfectly good tools with new stuff from a big store like Home Depot or Lowe's?
  - JAlexoid 4y ago
    People forget that Stanley #4 plane hasn't really changed in over 100 years. It's still one of the best tools out there. We dumped CVS because it was a poor tool, for the time. Subversion was better. Then completely distributed systems became better, because connectivity and computational power came about.
    - tolciho 4y ago
      CVS never managed to wedge itself and eat my files like Subversion did. I went back to CVS.
clpwn 4y ago
I feel like a lot of fantastic software is made by a small number of people whose explicit culture is a mix of abnormally strong opinionatedness plus the dedication to execute on that by developing the tools and flow that feel just right. Much like a lot of other "eccentric" artists in other realms, that eccentricity is, at least in part, a bravery of knowing what one wants and making that a reality, usually with compromises that others might not be comfortable making (efficiency, time, social interaction from a larger group, etc).
- awesomegoat_com 4y ago
  Totally agree. It is just allowing human element that creates quality craft. When you are following the best practices, you remove that human element (hyperbole, I know). When you force certain rules, jiras, stand-up, you increase predictability, but the cost is the lower quality, lower happiness and higher attrition.
  - chousuke 4y ago
    it's not that "best practices" or any of those things are what causes trouble; it's failing to recognize that they're just tools, and people will still be the ones doing the work. And people should never be treated as merely tools. You can use all of those things as to enable people to do things better and with less friction, but you also need to keep in mind that if a tool becomes more of a hindrance than a help, you should go looking for a new one.
    - diffxx 4y ago
      > it's not that "best practices" or any of those things are what causes trouble; it's failing to recognize that they're just tools, and people will still be the ones doing the work. And people should never be treated as merely tools. For me, the concept of best practices is pernicious because it is a delegation of authority to external consensus which inevitably will lead to people being treated as tools as they are forced to contort to said best practices. The moment something becomes best practice, it becomes dogma.
marcodiego 4y ago
I'm all for minimizing friction for contributors, but when I read things like: "The few core developers they have do not work with modern tools like git and collaboration tools like Github", I wonder if the collaboration from someone who refuses to send a patch to a mailing list (because it is not what they are used to and don't care to learn how to do) is really worth considering. I mean: if someone is not wanting to move a few millimeters out of their comfort zone to make a contribution is, very likely, someone who has very little commitment or will try to force their opinions and methods onto others.
- Kwpolska 4y ago
  SQLite does not accept any patches from anyone.
  - dathinab 4y ago
    It does but you have to go through the maintainers and they have to be in line with the core principles of SQLite and have the necessary code quality etc. I.e. it's hard to a point you can just say it's impossible for most people. But what the author of the article fails to mention is that many of the things libsql wants to add to sqlite are in direct conflict with the core principles of sqlite. E.g. SQLite: Max portability by depending on a _extreme_ small set of C-Standard C-Functions. libSQL: lets add io-uring a Linux specific functionality more complex then all the C-Standard C-Functions Sqlite depends on together. E.g. SQLite: Strongly focused on simplicity and avoidance of race conditions by having a serialized & snapshot isolation level without fork-the-world semantics (i.e. globally exclusive write lock). libSql: Lets make it distributed (which is fundamental in conflict with the transaction model, if you want to make it work well). E.g. SQLite: Small compact code base. libSql: Lets include a WASM runtime (which also is in conflict with max portability, and simplicity/project focus).
    - hanche 4y ago
      > It does but you have to go through the maintainers and they have to be in line with the core principles of SQLite and have the necessary code quality etc. Even so, I think they’ll prefer to rewrite the contribution. They need to be absolutely sure not to incorporate any copyright encumbered code by mistake.
kbenson 4y ago
Extremely well written and maintained and high quality as of now and having a plan to make sure that can continue in the future are sometimes entirely different things with needs that oppose each other. A single person can develop and release extremely high quality software, and as long as it meets the needs of the users (it's not missing a lot of features that a taking a long time to deliver), a single person in absolute control and writing all the code is probably a benefit in keeping it high quality and with less bugs. It may not follow that the same can be said a few years from now, or even a few months from now, since the bus factor of that project is one, and if "bus events" includes "I don't want to work on that anymore but nobody else knows it well at all" then for some users that's a problem (and for others not so much). On situation isn't necessarily better or worse than the other (and it's probably something in-between anyway), it really just depends on the project and the audience it's intended for. That audience might be somewhat self-selected by the style of development though.
- arka2147483647 4y ago
  > Extremely well written and maintained and high quality as of now ... As I see it, the quality comes from the fixed need, tight scope and small professional team Fixed need -> Somebody always needs a database Smaller scope -> Less features, less code, less bugs Professional team -> No newbies around to break things Now, to be sure, this kind of development model can only work for some projects.
  - dathinab 4y ago
    Also tooling focused on their dev flow. In difference to the article implying that they use out-date project tooling they don't(). They VCS isn't out-date but in some way more modern then git, it's just focused on dev flows similar to theirs to a point where using typical git dev flows will not work well. Similar not using GitHub is a more then right decisions for how the project is manage, github is too much focused on open contribution projects. (): You could argue they use "not modern" tools like C and similar to do modern things like fuzz testing. But the articles author clearly puts a focus on the project tooling highlighting git/GitHub so reading it as implying that their VCS is "not modern" i.e. outdated i.e. bad seem very reasonable IMHO.
ad404b8a372f2b9 4y ago
This part also rung some alarm bells for me. It makes me think the author is unable to see outside his bubble, and that feeling is only reinforced by the comments about Rust and the CoC in the Readme.
- ikiris 4y ago
  Yeah the guy clearly has some serious NIH syndrome.
lliamander 4y ago
Personally I find Fossil a really compelling VCS. I plan to use it for my next personal project.
tyingq 4y ago
Well, and while they don't use git, they do use Fossil. Their explanation for why doesn't make Fossil seem less modern. https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html
- fluidcruft 4y ago
  Actually leaves me seriously considering fossil rather than git for my next project.
  - Matumio 4y ago
    Agree, after reading up about fossil. Except for one thing: I don't want the "closed team" culture that was intentionally baked into the tool. When git replaced SVN, it was so empowering that I, as an individual, was able to use the full maintainer workflow without the blessing of a maintainer, privately by default. Before git, we saved the output of "svn diff" into a .patch file for tracking personal changes. When submitting a patch, the maintainer had to write a commit message for you. With some luck, you even got credited. For sharing a sensible feature-branch, you had to become a maintainer with full access. This higher bar has advantages (it tends to create more full-access maintainers, for one). However, it sends this message: "Yes open source, but you are not one of us." Yes, fossil has this great feature of showing "what was everyone up to after release X". I miss that in git. (Closest workaround: git fetch --all && gitk --all.) But if "everyone" means just the core devs, then I'm out.
    - gnubison 4y ago
      Fossil is decentralized, just like git?
    - badsectoracula 4y ago
      > I don't want the "closed team" culture that was intentionally baked into the tool. I've been using Fossil for years and TBH i don't see that "closed team" culture you speak of (though i also have almost all of my projects as "open source, not open contribution"). Fossil is a distributed version control and in fact it is "more" distributed than git if you consider that people tend to tie it with centralized services like GitHub to get more than just the VCS part. A Fossil repository contains not only the versioned files, but also a wiki, tickets/bugtracker, forum, chat room, blog/technotes - even the theme is part of it. And since it is a decentralized system, all of it are cloned when you clone the repository. AFAIK the only limitation (hasn't really tried it myself since i only use it solo) is that for security cloned users aren't "fully" cloned so you'd need to make new users in the cloned repository - you can use the same username though (but in commits, history, etc it'll appear as different users). It'd be useful if "user" and "identity" could be distinguished so that you can have the tool know that two usernames are really about the same person. Also Fossil works pretty much everywhere - a local server, as a FastCGI server, as a plain old CGI "script", you can even have it as a "CGI interpreter" for ".fossil" files (the repository files - the entire repository is stored in a single SQLite database file) which makes it usable with many shared web hosting services without needing root or even shell access. In a way that is the most decentralized you can go :-P.
choletentent 4y ago
Very similar approach is taken by the Lua developers.
bawolff 4y ago
This make it sound like sqlite isn't using source control at all. What they are actually doing is using a more obscure source control program than git. Honestly who cares? Source control is source control.
- bena 4y ago
  While Fossil may be obscure, it's also dog fooding for them. Fossil uses SQLite. It is built on top of SQLite.
1vuio0pswjnm7 4y ago
When NetBSD imported sqlite and sqlite3 into their base system that was a signal to me that SQLite is no-nonsense and reliable. That was many years ago, around 2011 I think. Not sure why SQLite is getting all the attention on HN lately. Usually more attention means more pressure to adopt so-called "modern" practices and other BS. SQLite is interesting to me because like djb's software its author is not interested in copyrights.^1 1. https://cr.yp.to/publicdomain.html https://cr.yp.to/publicdomain.html ^2 Here is how Hipp abandons his copyrights: The author disclaims copyright to this source code. In place of a legal notice, here is a blessing: May you do good and not evil. May you find forgiveness for yourself and forgive others. May you share freely, never taking more than you give. Apparently this is not be enough to convince some folks they can use the code (maybe they really are doing evil), and so there is also a strange set of "reassurances" on the website: https://sqlite.org/copyright.html https://sqlite.org/copyright.html It seems that is still not enough and so there is actually an option to pay for a "license" to software that is in the public domain. Don't laugh. https://sqlite.org/purchase/license https://sqlite.org/purchase/license 2. I seem to recall an open source OS project or two making a fuss about djb's software being public domain but perhaps I am remembering incorrectly.
- bombcar 4y ago
  Public Domain doesn't exist in some countries, so people/companies from those countries want an assurance that their country's laws understands.
deterministic 4y ago
In other words, SQLite is clear evidence that using “modern” tools, “best” practices etc. is not necessary to creating world class software. And other projects clearly demonstrate that using “modern” tools and “best” practices often still result in really bad low quality software. So in conclusion: “modern” tools and “best” practices are empirically proven to not be important when it comes to creating world class software.
- dathinab 4y ago
  but SQLite IS using modern tools, you could say their VCS is more modern then git. It is just not compatible with a lot of git work flows due to being focused on workflow not working well with git. It is also following modern best practice like: - use the best tool for the job (i.e. not git or GitHub) - consider upfront how the project can long term be maintained (i.e. realize that you don't have resources to manage/moderate an public issue tracker/PRs and that you don't want to delegate this work to 3rd parties you barely know) - keep things simple, i.e. no global exclusive write lock and serialized isolation level (instead of subtle race condition and/or fork the work handling etc.) - test a lot, use fuzzing etc. - limit features to you targeted use-cases to keep complexity in check (maintainability, bug avoidance) - opinionated code style, formatting - clear cut well defined dev/contribution flow (for the few which can contribute directly) I.e. if we ignore superficial modern best practices like "use exactly this tool" I don't know which modern best practice it does not fulfill(). Through some are not fulfilled in the way people are used to. (): Ok, maybe they don't keep to: Prefer languages with more guard rails as far as possible. Through due to their targeted compatibility/portability C is kinda the only option.
binkHN 4y ago
> The funny thing about this comment is that SQLite is as close to the gold standard of software quality that we have in the open source world. SQLite is the only program that I've ever used that reliably gets better with every release and never regresses. Could it be that this is precisely because they don't use "modern tools" and accept outside contributions? Reminds me of OpenBSD, who still primarily uses CVS for source control.
nxpnsv 4y ago
Yup, the choice of tools is a terrible metric for software quality.

by diffxx 4y ago

tingletech 4y ago

I think you are right. Their rational for not using git seems reasonable to me https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html

deleted 4y ago

[deleted]

Ar-Curunir 4y ago

You're conflating two different arguments: not using modern tools, and not accepting outside contributions. It's certainly possible that limiting contributions to a set of trusted contributors helps things move smoothly. However it's not clear at all that using old tools has the same effect.

notRobot 4y ago
They don't use old tools, they use different tools. Git development started in 2005, Fossil development started in 2006, they'ré equally modern, and largely do the same things, just in different ways.
- diffxx 4y ago
  Also, Fossil is essentially implemented _in_ SQLite. Fossil is used to develop SQLite which is used to implement Fossil. It's a virtuous cycle. For the SQLite project, using Fossil is obviously superior to git. This doesn't mean that arbitrary projects should use Fossil over git.
  - ThunderSizzle 4y ago
    The opposite can be said though, but git arbitrarily won over a bunch of other DVCS systems (another e.g. hg), mainly because of bandwagon and marketing.
ok_dad 4y ago
> old tools I have some of my great-grandpa's carpentry tools, and I use them often. I guess I should go out and replace perfectly good tools with new stuff from a big store like Home Depot or Lowe's?
- JAlexoid 4y ago
  People forget that Stanley #4 plane hasn't really changed in over 100 years. It's still one of the best tools out there. We dumped CVS because it was a poor tool, for the time. Subversion was better. Then completely distributed systems became better, because connectivity and computational power came about.
  - tolciho 4y ago
    CVS never managed to wedge itself and eat my files like Subversion did. I went back to CVS.

clpwn 4y ago

I feel like a lot of fantastic software is made by a small number of people whose explicit culture is a mix of abnormally strong opinionatedness plus the dedication to execute on that by developing the tools and flow that feel just right. Much like a lot of other "eccentric" artists in other realms, that eccentricity is, at least in part, a bravery of knowing what one wants and making that a reality, usually with compromises that others might not be comfortable making (efficiency, time, social interaction from a larger group, etc).

awesomegoat_com 4y ago
Totally agree. It is just allowing human element that creates quality craft. When you are following the best practices, you remove that human element (hyperbole, I know). When you force certain rules, jiras, stand-up, you increase predictability, but the cost is the lower quality, lower happiness and higher attrition.
- chousuke 4y ago
  it's not that "best practices" or any of those things are what causes trouble; it's failing to recognize that they're just tools, and people will still be the ones doing the work. And people should never be treated as merely tools. You can use all of those things as to enable people to do things better and with less friction, but you also need to keep in mind that if a tool becomes more of a hindrance than a help, you should go looking for a new one.
  - diffxx 4y ago
    > it's not that "best practices" or any of those things are what causes trouble; it's failing to recognize that they're just tools, and people will still be the ones doing the work. And people should never be treated as merely tools. For me, the concept of best practices is pernicious because it is a delegation of authority to external consensus which inevitably will lead to people being treated as tools as they are forced to contort to said best practices. The moment something becomes best practice, it becomes dogma.

marcodiego 4y ago

I'm all for minimizing friction for contributors, but when I read things like: "The few core developers they have do not work with modern tools like git and collaboration tools like Github", I wonder if the collaboration from someone who refuses to send a patch to a mailing list (because it is not what they are used to and don't care to learn how to do) is really worth considering. I mean: if someone is not wanting to move a few millimeters out of their comfort zone to make a contribution is, very likely, someone who has very little commitment or will try to force their opinions and methods onto others.

Kwpolska 4y ago
SQLite does not accept any patches from anyone.
- dathinab 4y ago
  It does but you have to go through the maintainers and they have to be in line with the core principles of SQLite and have the necessary code quality etc. I.e. it's hard to a point you can just say it's impossible for most people. But what the author of the article fails to mention is that many of the things libsql wants to add to sqlite are in direct conflict with the core principles of sqlite. E.g. SQLite: Max portability by depending on a _extreme_ small set of C-Standard C-Functions. libSQL: lets add io-uring a Linux specific functionality more complex then all the C-Standard C-Functions Sqlite depends on together. E.g. SQLite: Strongly focused on simplicity and avoidance of race conditions by having a serialized & snapshot isolation level without fork-the-world semantics (i.e. globally exclusive write lock). libSql: Lets make it distributed (which is fundamental in conflict with the transaction model, if you want to make it work well). E.g. SQLite: Small compact code base. libSql: Lets include a WASM runtime (which also is in conflict with max portability, and simplicity/project focus).
  - hanche 4y ago
    > It does but you have to go through the maintainers and they have to be in line with the core principles of SQLite and have the necessary code quality etc. Even so, I think they’ll prefer to rewrite the contribution. They need to be absolutely sure not to incorporate any copyright encumbered code by mistake.

kbenson 4y ago

Extremely well written and maintained and high quality as of now and having a plan to make sure that can continue in the future are sometimes entirely different things with needs that oppose each other. A single person can develop and release extremely high quality software, and as long as it meets the needs of the users (it's not missing a lot of features that a taking a long time to deliver), a single person in absolute control and writing all the code is probably a benefit in keeping it high quality and with less bugs. It may not follow that the same can be said a few years from now, or even a few months from now, since the bus factor of that project is one, and if "bus events" includes "I don't want to work on that anymore but nobody else knows it well at all" then for some users that's a problem (and for others not so much). On situation isn't necessarily better or worse than the other (and it's probably something in-between anyway), it really just depends on the project and the audience it's intended for. That audience might be somewhat self-selected by the style of development though.

arka2147483647 4y ago
> Extremely well written and maintained and high quality as of now ... As I see it, the quality comes from the fixed need, tight scope and small professional team Fixed need -> Somebody always needs a database Smaller scope -> Less features, less code, less bugs Professional team -> No newbies around to break things Now, to be sure, this kind of development model can only work for some projects.
- dathinab 4y ago
  Also tooling focused on their dev flow. In difference to the article implying that they use out-date project tooling they don't(). They VCS isn't out-date but in some way more modern then git, it's just focused on dev flows similar to theirs to a point where using typical git dev flows will not work well. Similar not using GitHub is a more then right decisions for how the project is manage, github is too much focused on open contribution projects. (): You could argue they use "not modern" tools like C and similar to do modern things like fuzz testing. But the articles author clearly puts a focus on the project tooling highlighting git/GitHub so reading it as implying that their VCS is "not modern" i.e. outdated i.e. bad seem very reasonable IMHO.

ad404b8a372f2b9 4y ago

This part also rung some alarm bells for me. It makes me think the author is unable to see outside his bubble, and that feeling is only reinforced by the comments about Rust and the CoC in the Readme.

ikiris 4y ago
Yeah the guy clearly has some serious NIH syndrome.

lliamander 4y ago

Personally I find Fossil a really compelling VCS. I plan to use it for my next personal project.

tyingq 4y ago

Well, and while they don't use git, they do use Fossil. Their explanation for why doesn't make Fossil seem less modern. https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html

fluidcruft 4y ago
Actually leaves me seriously considering fossil rather than git for my next project.
- Matumio 4y ago
  Agree, after reading up about fossil. Except for one thing: I don't want the "closed team" culture that was intentionally baked into the tool. When git replaced SVN, it was so empowering that I, as an individual, was able to use the full maintainer workflow without the blessing of a maintainer, privately by default. Before git, we saved the output of "svn diff" into a .patch file for tracking personal changes. When submitting a patch, the maintainer had to write a commit message for you. With some luck, you even got credited. For sharing a sensible feature-branch, you had to become a maintainer with full access. This higher bar has advantages (it tends to create more full-access maintainers, for one). However, it sends this message: "Yes open source, but you are not one of us." Yes, fossil has this great feature of showing "what was everyone up to after release X". I miss that in git. (Closest workaround: git fetch --all && gitk --all.) But if "everyone" means just the core devs, then I'm out.
  - gnubison 4y ago
    Fossil is decentralized, just like git?
  - badsectoracula 4y ago
    > I don't want the "closed team" culture that was intentionally baked into the tool. I've been using Fossil for years and TBH i don't see that "closed team" culture you speak of (though i also have almost all of my projects as "open source, not open contribution"). Fossil is a distributed version control and in fact it is "more" distributed than git if you consider that people tend to tie it with centralized services like GitHub to get more than just the VCS part. A Fossil repository contains not only the versioned files, but also a wiki, tickets/bugtracker, forum, chat room, blog/technotes - even the theme is part of it. And since it is a decentralized system, all of it are cloned when you clone the repository. AFAIK the only limitation (hasn't really tried it myself since i only use it solo) is that for security cloned users aren't "fully" cloned so you'd need to make new users in the cloned repository - you can use the same username though (but in commits, history, etc it'll appear as different users). It'd be useful if "user" and "identity" could be distinguished so that you can have the tool know that two usernames are really about the same person. Also Fossil works pretty much everywhere - a local server, as a FastCGI server, as a plain old CGI "script", you can even have it as a "CGI interpreter" for ".fossil" files (the repository files - the entire repository is stored in a single SQLite database file) which makes it usable with many shared web hosting services without needing root or even shell access. In a way that is the most decentralized you can go :-P.

choletentent 4y ago

Very similar approach is taken by the Lua developers.

bawolff 4y ago

This make it sound like sqlite isn't using source control at all. What they are actually doing is using a more obscure source control program than git. Honestly who cares? Source control is source control.

bena 4y ago
While Fossil may be obscure, it's also dog fooding for them. Fossil uses SQLite. It is built on top of SQLite.

1vuio0pswjnm7 4y ago

When NetBSD imported sqlite and sqlite3 into their base system that was a signal to me that SQLite is no-nonsense and reliable. That was many years ago, around 2011 I think. Not sure why SQLite is getting all the attention on HN lately. Usually more attention means more pressure to adopt so-called "modern" practices and other BS. SQLite is interesting to me because like djb's software its author is not interested in copyrights.^1 1. https://cr.yp.to/publicdomain.html https://cr.yp.to/publicdomain.html ^2 Here is how Hipp abandons his copyrights: The author disclaims copyright to this source code. In place of a legal notice, here is a blessing: May you do good and not evil. May you find forgiveness for yourself and forgive others. May you share freely, never taking more than you give. Apparently this is not be enough to convince some folks they can use the code (maybe they really are doing evil), and so there is also a strange set of "reassurances" on the website: https://sqlite.org/copyright.html https://sqlite.org/copyright.html It seems that is still not enough and so there is actually an option to pay for a "license" to software that is in the public domain. Don't laugh. https://sqlite.org/purchase/license https://sqlite.org/purchase/license 2. I seem to recall an open source OS project or two making a fuss about djb's software being public domain but perhaps I am remembering incorrectly.

bombcar 4y ago
Public Domain doesn't exist in some countries, so people/companies from those countries want an assurance that their country's laws understands.

deterministic 4y ago

In other words, SQLite is clear evidence that using “modern” tools, “best” practices etc. is not necessary to creating world class software. And other projects clearly demonstrate that using “modern” tools and “best” practices often still result in really bad low quality software. So in conclusion: “modern” tools and “best” practices are empirically proven to not be important when it comes to creating world class software.

dathinab 4y ago
but SQLite IS using modern tools, you could say their VCS is more modern then git. It is just not compatible with a lot of git work flows due to being focused on workflow not working well with git. It is also following modern best practice like: - use the best tool for the job (i.e. not git or GitHub) - consider upfront how the project can long term be maintained (i.e. realize that you don't have resources to manage/moderate an public issue tracker/PRs and that you don't want to delegate this work to 3rd parties you barely know) - keep things simple, i.e. no global exclusive write lock and serialized isolation level (instead of subtle race condition and/or fork the work handling etc.) - test a lot, use fuzzing etc. - limit features to you targeted use-cases to keep complexity in check (maintainability, bug avoidance) - opinionated code style, formatting - clear cut well defined dev/contribution flow (for the few which can contribute directly) I.e. if we ignore superficial modern best practices like "use exactly this tool" I don't know which modern best practice it does not fulfill(). Through some are not fulfilled in the way people are used to. (): Ok, maybe they don't keep to: Prefer languages with more guard rails as far as possible. Through due to their targeted compatibility/portability C is kinda the only option.

binkHN 4y ago

> The funny thing about this comment is that SQLite is as close to the gold standard of software quality that we have in the open source world. SQLite is the only program that I've ever used that reliably gets better with every release and never regresses. Could it be that this is precisely because they don't use "modern tools" and accept outside contributions? Reminds me of OpenBSD, who still primarily uses CVS for source control.

nxpnsv 4y ago

Yup, the choice of tools is a terrible metric for software quality.