7 ms·

Hey all, author here. FYI, the post is still in its unpublished state. It's basically right, but I've been meaning to edit it for tone and rewrite the market f

Hey all, author here. FYI, the post is still in its unpublished state. It's basically right, but I've been meaning to edit it for tone and rewrite the market failure section for clarity. Didn't get the chance to do that before it made it on HN, so keep in mind that you're reading a (late) draft.

creativityland 10y ago
Thanks for pointing that out, just noticed the "/_drafts/why-rethinkdb-failed.md".
boulos 10y ago
First, thanks for your candor in this. If you're open to edits, the $200k revenue/employee rule of thumb really doesn't make a lot of sense when you're comparing your three alternate business models (Hosted Rethink, DBaaS Rethink and "Hey, maybe PaaS on top of Rethink?"). Like you, I thought it would be way too hard to run a service (my own company was encouraged to do so, and we shied away for it for the same reason you stated). However, having seen it now from the inside for GCE for nearly 4 years, I can say it's much easier to "service-ize" yourself than it is to have built a product people want. And moreover, the shell scripts and operations stuff really scales (effectively, the hosted DB offering is the binary plus a bit of bash, while the other offerings require yet more "not done before" software). Even more surprisingly, this statement: > Managed hosting is essentially running the database for people on AWS so they don't have to. The alternative to using these services is setting up the database on AWS yourself. That's a pain, but it isn't actually that hard. So there is a very hard cap on how much managed database hosting services can charge. turns out to just not be true in practice. People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them. It turns out that people really like outsourcing even a small amount of pain, but that we're (as engineers) easily blindsided to "Um, why would I pay you XX% over the raw VM price? You're just running some shell scripts for me". Little things like automatically updating to the latest version, configuration replication, etc. are things that nobody will bat at an eye at paying you for (I believe in the DB space in particular, it's because the overall cost of your DB is dwarfed by "All the rest", so it's a good trade of people time versus $$s). I hope this doesn't come across as Monday-morning quarterbacking, but if I did mine over again I'd take the "Build a great piece of software, and even if it's open, service-ize it for folks". It's true that you're competing with the Cloud providers, and that it seems like you wouldn't really be able to get people to pay you for it (and it's not your core competency), but I think it's the best option for this flavor of infrastructure software moving forward.
- craigkerstiens 10y ago
  > If you're open to edits, the $200k revenue/employee rule of thumb really doesn't make a lot of sense when you're comparing your three alternate business models Sure, but for many venture funded companies and even large enterprises top-line is the top metric you're focused on. If you're in a growth industry it's about top line revenue, capturing market share, and cost of underlying bits will eventually come down. > turns out to just not be true in practice. People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them. For infrastructure providers to "service-ize" you can set cost as a much smaller markup on the cost of the raw infrastructure. Most large organizations (AWS/GCE) have a model where they give some credit for the underlying infrastructure back to the team that servicized things. This is quite a bit different from a smaller startup that still needs to make some reasonable margin but has significant cost of goods of the infrastructure itself. At the same time I fully agree with the notion that you should build and run a service, but if the marketing or even product perspective of such a thing is we installed a VM for you you're entirely missing the point. Having built an as-a-service product a few times over, there is a lot of engineering and product work that goes into it. Turn key backups, point in time recovery, high availability, performance monitoring are all not just installing a VM. And it's very different from building a core database engine. While there can be many benefits from collaborating on them, they are very different skill sets and the notion of focus shouldn't be underweighted.
- vosper 10y ago
  To back you up on this, at the last place I worked we ran our own MySQL master and slaves for years, with moving to RDS always on the back burner. Finally completing that migration and shutting down our own servers was a big achievement. Never looked back, and were happy to be paying AWS to take care of the DBs for us.
- gedrap 10y ago
  >>> People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them. As a happy RDS user, I totally agree. Surely, I could run MySQL and the result would be mostly fine, after some mistakes and lessons learned. But all the things such as upgrading, etc still take time, add a bit of stress, one more thing to care about. Could that time and energy be spent on more valuable (from business point of view) activities? Yes. I have regretted this decision.
keithnz 10y ago
Nice write up! My outside personal perspective was that you needed to endure for longer. Things like Mongo rode the "Relational is a deadend, NoSQL to the rescue!" wave and gathered momentum before people started fully understanding the consequences of choosing Mongo. Now it seems there's a lot more caution being taken. Anecdotal accounts of people having success with things are taken with a grain of salt. People seem to be looking for more of a tidal wave of acceptance. As an aside, lately it seems it's "OO is a deadend, Functional to the rescue!" ... so maybe you can leverage that wave instead... or deep learning... OverThinkDB maybe :)
abraae 10y ago
Kudos on a magnificent post, and of course commiserations. One thing resonated strongly with me. When we started out many years ago someone said to me that the worst market you could go after was to target developers. Case in point - every developer who's ever put up a web site has built or thought about building a CMS. There must be thousands upon thousands of them, virtually all with a price of $0. Who would want to sell a CMS product? We heeded that advice and I often reflect on it during the sales process when we have the "lets just run your offering past the IT team" meeting. So often, the line of questioning from the smartypants dudes in the room is all about tripping us up, finding our weak spot (I'm a techy so I get it - I think like this myself). The best you can normally come out of that meeting with is grudging acceptance from IT that a SaaS solution should be OK, given that the business is in a rush and all, and given that IT has other priorities. (To be fair its much less like this these days, but a few years ago this was the norm). By contrast, showing your product to a business person is a breath of fresh air. They don't want to build it themselves, they don't really care what's under the bonnet, they just want good, quick solutions to their actual problems, so they can go home at night and sit down to Netflix. HR people (our target market) are even nicer. What's more those business people want to pay for your solution. A quick way to kill the deal is to joyously tell them "its free!". They need to understand how you get your buck at the end of the day. They'll never buy until they understand that. And the best (because its the simplest) answer is "we've got the best product, so we charge good money for it".
- donmatito 10y ago
  These anecdotes are gold
- cmdkeen 10y ago
  IT people try and "trip you up" because we've been burnt so many times in the past with systems that don't do what is promised by the sales people, don't integrate well and who stiff you during the implementation phase. HR people are some of the worst because everything is super secret and they don't want to get IT involved, then they go and buy a system that lets you insert a carriage return into the phone number field and produces CSV files that don't have primary keys for data extracts.
mifeng 10y ago
As a former startup founder, I totally empathize - it's always clearer with hindsight but it's important to honestly reflect so you can apply the lessons learned to the next turn of the ferris wheel. > We set out to build a good database system, but users wanted a good way to do X. If you replace "database system" with "[any product]," it encapsulates the reason why many startups fail. I was guilty of it too. I think it's a common pitfall for technical founders who tend to think in terms of solutions rather than problems. If you have some free time, I would recommend the book What Customers Want by Anthony Ulwick, which offers a systematic approach to formulating a product that satisfies a market's underserved needs.
- timv 10y ago
  > I think it's a common pitfall for technical founders There's a very closely related form that is common for non-technical founders which is "We're going to use technology to fix ____ industry" A founder with experience in a particular industry may see how inefficient it is, and how much scope there is for improvement based on technological solutions, but business live-an-die by the question: "Are there enough people who will pay us to solve this problem for them?" Superficially, it seems like "I can make your business run more efficiently" is a reasonable approximation for "I have something that you will pay money for", but it has a very similar value-gap to "I can provide you with a technically better database". "More efficient" and "technically better" are both things that ought to be valuable to customers, but often aren't valuable enough to get them to hand over their money.
adictator 10y ago
Thank you for the detailed analysis & post. I am myself embarking on a startup journey, albeit in the world of consulting & I wanted to let you know that your in depth writeup was extremely valuable & in many ways poignant to me. There were so many learnings in there and the way your bared it all, it feels it must have been excruciatingly hard to let go of your company (& co-workers) in the end. Thanks again & I wish you all the very best for your next venture - wiser & better.
sroussey 10y ago
The key to building developer tools is to build the ones that a developer needs but has no interest in creating. Backend for mobile, infrastructure for backend, etc. Just don't create front end tools for front end developers, for example. Firebug had a donate button and we funneled all of it to volunteers in places where the currency was weak to make it at least seem material.
- FooBarWidget 10y ago
  I don't think it's that simple. Which developer wants to build a reliable, realtime database?
travisoliphant 10y ago
Kudos on the post and for sharing. I really enjoyed reading the candor and hearing from your experiences. I heard amazing things about RethinkDB and admire your team for what you did.
lacker 10y ago
This was a really interesting post. Thanks for writing it. First with MySQL and then with MongoDB, a pattern is emerging. There's a popular open-source database. Its feature set is awesome and the ecosystem of software on top of it is good because lots of people are using it, but it's buggy and unreliable. So it's controversial. Since it's popular, it keeps being developed, and over time, it slowly gets more reliable. To me this post is a reminder that, just because I can see clear flaws with a competing product, it doesn't mean those flaws are exploitable. Better to focus on what your own customers are demanding than on criticisms of your competitor.
- sgift 10y ago
  > (...) Since it's popular, it keeps being developed, and over time, it slowly gets more reliable. Or people simply don't care/are not willing to pay for alternatives. MongoDB looks as unreliable as it was on the first day, but somehow people don't seem to care. I hope it's because their use-cases can live with the unreliability, but in fear it's because "won't happen to me, just to others".
- niftich 10y ago
  Market timing, excitement (some of which later turns into hype), mindshare, and marketing make for a difficult combo to beat. The post-mortem covered addressed market timing and hinted at the rest, but is reluctant to call out MongoDB's marketing. I can't help but wonder if the story had been different if the RethinkDB devs organized a bunch of codecamps and positioned their db as the 'default choice'. This is how Mongo gained a ton of mindshare, helped by other trends at the time, like the NoSQL wave, the Node.js boom, and the renaissance of client-side JS development.
- jeremyjh 10y ago
  The problem with MySQL early on was exactly its feature set. Fifteen years ago it was very far behind Postgres yet much more popular. I do not think it even had InnoDB/transactions at that point (or almost no one used it), definitely did not have user defined functions, procedures and many other features developers took for granted in commercial RDBMS. Like MongoDB, it was popular mostly for being popular, which is a nice gig if you can get it.
atmosx 10y ago
Thanks for the post. One can feel your pain flowing through it. I have a rather naive question: Why do you recommend "the Economist" as oppose to something like the HBR?
- noir-york 10y ago
  I've read the Economist for the last 20 years and the HBR for a few months before I dropped it. The Economist offers insight, thoughtful analysis and writes about the world: literally but also politics, culture, and science. The obituary is surprisingly fascinating for instance. You may not always agree with its position, but you know that their position will be worth engaging with and thinking about. No, I don't work for the Economist, I just appreciate thoughtful articles. Same goes for Private Eye, Foreign Affairs, New Yorker.
  - danieltillett 10y ago
    The best obituaries are in the Telegraph. I am still angry they have put them all behind a paywall :(
    - noir-york 10y ago
      Aha interesting! Never read their obits. I find Evans-Pritchard a good read.
Patrick_Devine 10y ago
Did you ever consider partnering with a larger vendor? Figuring out the right GTM is tough, and the timing was weird, but GOOG and MSFT must have been pretty desperate for a NoSQL solution 2013-2014 to compete with DynamoDB. Firebase got scooped up in October 2014, but it wasn't until April 2015 when Azure announced DocumentDB.
v3ss0n 10y ago
Sorry i am the one who leaked . @coffeemug we greatly appreciate your effort and rethinkDB is well architectured database in existance. We gonna keep using it and contribute to Rethinkdb .
patates 10y ago
It seems like you have a great ability to self-evaluate. Many of my friends and I, after reading your post, agree that we would be very willing to work in a team managed by people like you.
danieltillett 10y ago
While I feel for you because failure hurts so much, congratulations on learning from your experience. I know this won't make you feel any better, but the next time you try things will be so much easier. By the way the tone is fine given your experience.
atis 10y ago
Thanks for all your work. I understand that you're waiting for a legal framework to accept donations as an organization, but there was an article recently about an individual GIMP developer being funded on patreon. Is this something you would consider? I'd be happy to contribute to someone who's actively working on RethinkDB (of course without any backer rewards or similar expectations), and perhaps others would as well.
martincmartin 10y ago
Thanks for writing this, and writing it with candor. What do you think of Spolsky's "Good software takes 10 years"? https://www.joelonsoftware.com/2001/07/21/good-software-takes-ten-years-get-used-to-it/ https://www.joelonsoftware.com/2001/07/21/good-software-take...
scott_s 10y ago
I hope my finished writing is as good as your draft.

creativityland 10y ago

Thanks for pointing that out, just noticed the "/_drafts/why-rethinkdb-failed.md".

boulos 10y ago

First, thanks for your candor in this. If you're open to edits, the $200k revenue/employee rule of thumb really doesn't make a lot of sense when you're comparing your three alternate business models (Hosted Rethink, DBaaS Rethink and "Hey, maybe PaaS on top of Rethink?"). Like you, I thought it would be way too hard to run a service (my own company was encouraged to do so, and we shied away for it for the same reason you stated). However, having seen it now from the inside for GCE for nearly 4 years, I can say it's much easier to "service-ize" yourself than it is to have built a product people want. And moreover, the shell scripts and operations stuff really scales (effectively, the hosted DB offering is the binary plus a bit of bash, while the other offerings require yet more "not done before" software). Even more surprisingly, this statement: > Managed hosting is essentially running the database for people on AWS so they don't have to. The alternative to using these services is setting up the database on AWS yourself. That's a pain, but it isn't actually that hard. So there is a very hard cap on how much managed database hosting services can charge. turns out to just not be true in practice. People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them. It turns out that people really like outsourcing even a small amount of pain, but that we're (as engineers) easily blindsided to "Um, why would I pay you XX% over the raw VM price? You're just running some shell scripts for me". Little things like automatically updating to the latest version, configuration replication, etc. are things that nobody will bat at an eye at paying you for (I believe in the DB space in particular, it's because the overall cost of your DB is dwarfed by "All the rest", so it's a good trade of people time versus $$s). I hope this doesn't come across as Monday-morning quarterbacking, but if I did mine over again I'd take the "Build a great piece of software, and even if it's open, service-ize it for folks". It's true that you're competing with the Cloud providers, and that it seems like you wouldn't really be able to get people to pay you for it (and it's not your core competency), but I think it's the best option for this flavor of infrastructure software moving forward.

craigkerstiens 10y ago
> If you're open to edits, the $200k revenue/employee rule of thumb really doesn't make a lot of sense when you're comparing your three alternate business models Sure, but for many venture funded companies and even large enterprises top-line is the top metric you're focused on. If you're in a growth industry it's about top line revenue, capturing market share, and cost of underlying bits will eventually come down. > turns out to just not be true in practice. People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them. For infrastructure providers to "service-ize" you can set cost as a much smaller markup on the cost of the raw infrastructure. Most large organizations (AWS/GCE) have a model where they give some credit for the underlying infrastructure back to the team that servicized things. This is quite a bit different from a smaller startup that still needs to make some reasonable margin but has significant cost of goods of the infrastructure itself. At the same time I fully agree with the notion that you should build and run a service, but if the marketing or even product perspective of such a thing is we installed a VM for you you're entirely missing the point. Having built an as-a-service product a few times over, there is a lot of engineering and product work that goes into it. Turn key backups, point in time recovery, high availability, performance monitoring are all not just installing a VM. And it's very different from building a core database engine. While there can be many benefits from collaborating on them, they are very different skill sets and the notion of focus shouldn't be underweighted.
vosper 10y ago
To back you up on this, at the last place I worked we ran our own MySQL master and slaves for years, with moving to RDS always on the back burner. Finally completing that migration and shutting down our own servers was a big achievement. Never looked back, and were happy to be paying AWS to take care of the DBs for us.
gedrap 10y ago
>>> People pay us (Cloud SQL) and AWS (RDS) a surprising amount of money to run MySQL in a VM for them. As a happy RDS user, I totally agree. Surely, I could run MySQL and the result would be mostly fine, after some mistakes and lessons learned. But all the things such as upgrading, etc still take time, add a bit of stress, one more thing to care about. Could that time and energy be spent on more valuable (from business point of view) activities? Yes. I have regretted this decision.

keithnz 10y ago

Nice write up! My outside personal perspective was that you needed to endure for longer. Things like Mongo rode the "Relational is a deadend, NoSQL to the rescue!" wave and gathered momentum before people started fully understanding the consequences of choosing Mongo. Now it seems there's a lot more caution being taken. Anecdotal accounts of people having success with things are taken with a grain of salt. People seem to be looking for more of a tidal wave of acceptance. As an aside, lately it seems it's "OO is a deadend, Functional to the rescue!" ... so maybe you can leverage that wave instead... or deep learning... OverThinkDB maybe :)

abraae 10y ago

Kudos on a magnificent post, and of course commiserations. One thing resonated strongly with me. When we started out many years ago someone said to me that the worst market you could go after was to target developers. Case in point - every developer who's ever put up a web site has built or thought about building a CMS. There must be thousands upon thousands of them, virtually all with a price of $0. Who would want to sell a CMS product? We heeded that advice and I often reflect on it during the sales process when we have the "lets just run your offering past the IT team" meeting. So often, the line of questioning from the smartypants dudes in the room is all about tripping us up, finding our weak spot (I'm a techy so I get it - I think like this myself). The best you can normally come out of that meeting with is grudging acceptance from IT that a SaaS solution should be OK, given that the business is in a rush and all, and given that IT has other priorities. (To be fair its much less like this these days, but a few years ago this was the norm). By contrast, showing your product to a business person is a breath of fresh air. They don't want to build it themselves, they don't really care what's under the bonnet, they just want good, quick solutions to their actual problems, so they can go home at night and sit down to Netflix. HR people (our target market) are even nicer. What's more those business people want to pay for your solution. A quick way to kill the deal is to joyously tell them "its free!". They need to understand how you get your buck at the end of the day. They'll never buy until they understand that. And the best (because its the simplest) answer is "we've got the best product, so we charge good money for it".

donmatito 10y ago
These anecdotes are gold
cmdkeen 10y ago
IT people try and "trip you up" because we've been burnt so many times in the past with systems that don't do what is promised by the sales people, don't integrate well and who stiff you during the implementation phase. HR people are some of the worst because everything is super secret and they don't want to get IT involved, then they go and buy a system that lets you insert a carriage return into the phone number field and produces CSV files that don't have primary keys for data extracts.

mifeng 10y ago

As a former startup founder, I totally empathize - it's always clearer with hindsight but it's important to honestly reflect so you can apply the lessons learned to the next turn of the ferris wheel. > We set out to build a good database system, but users wanted a good way to do X. If you replace "database system" with "[any product]," it encapsulates the reason why many startups fail. I was guilty of it too. I think it's a common pitfall for technical founders who tend to think in terms of solutions rather than problems. If you have some free time, I would recommend the book What Customers Want by Anthony Ulwick, which offers a systematic approach to formulating a product that satisfies a market's underserved needs.

timv 10y ago
> I think it's a common pitfall for technical founders There's a very closely related form that is common for non-technical founders which is "We're going to use technology to fix ____ industry" A founder with experience in a particular industry may see how inefficient it is, and how much scope there is for improvement based on technological solutions, but business live-an-die by the question: "Are there enough people who will pay us to solve this problem for them?" Superficially, it seems like "I can make your business run more efficiently" is a reasonable approximation for "I have something that you will pay money for", but it has a very similar value-gap to "I can provide you with a technically better database". "More efficient" and "technically better" are both things that ought to be valuable to customers, but often aren't valuable enough to get them to hand over their money.

adictator 10y ago

Thank you for the detailed analysis & post. I am myself embarking on a startup journey, albeit in the world of consulting & I wanted to let you know that your in depth writeup was extremely valuable & in many ways poignant to me. There were so many learnings in there and the way your bared it all, it feels it must have been excruciatingly hard to let go of your company (& co-workers) in the end. Thanks again & I wish you all the very best for your next venture - wiser & better.

sroussey 10y ago

The key to building developer tools is to build the ones that a developer needs but has no interest in creating. Backend for mobile, infrastructure for backend, etc. Just don't create front end tools for front end developers, for example. Firebug had a donate button and we funneled all of it to volunteers in places where the currency was weak to make it at least seem material.

FooBarWidget 10y ago
I don't think it's that simple. Which developer wants to build a reliable, realtime database?

travisoliphant 10y ago

Kudos on the post and for sharing. I really enjoyed reading the candor and hearing from your experiences. I heard amazing things about RethinkDB and admire your team for what you did.

lacker 10y ago

This was a really interesting post. Thanks for writing it. First with MySQL and then with MongoDB, a pattern is emerging. There's a popular open-source database. Its feature set is awesome and the ecosystem of software on top of it is good because lots of people are using it, but it's buggy and unreliable. So it's controversial. Since it's popular, it keeps being developed, and over time, it slowly gets more reliable. To me this post is a reminder that, just because I can see clear flaws with a competing product, it doesn't mean those flaws are exploitable. Better to focus on what your own customers are demanding than on criticisms of your competitor.

sgift 10y ago
> (...) Since it's popular, it keeps being developed, and over time, it slowly gets more reliable. Or people simply don't care/are not willing to pay for alternatives. MongoDB looks as unreliable as it was on the first day, but somehow people don't seem to care. I hope it's because their use-cases can live with the unreliability, but in fear it's because "won't happen to me, just to others".
niftich 10y ago
Market timing, excitement (some of which later turns into hype), mindshare, and marketing make for a difficult combo to beat. The post-mortem covered addressed market timing and hinted at the rest, but is reluctant to call out MongoDB's marketing. I can't help but wonder if the story had been different if the RethinkDB devs organized a bunch of codecamps and positioned their db as the 'default choice'. This is how Mongo gained a ton of mindshare, helped by other trends at the time, like the NoSQL wave, the Node.js boom, and the renaissance of client-side JS development.
jeremyjh 10y ago
The problem with MySQL early on was exactly its feature set. Fifteen years ago it was very far behind Postgres yet much more popular. I do not think it even had InnoDB/transactions at that point (or almost no one used it), definitely did not have user defined functions, procedures and many other features developers took for granted in commercial RDBMS. Like MongoDB, it was popular mostly for being popular, which is a nice gig if you can get it.

atmosx 10y ago

Thanks for the post. One can feel your pain flowing through it. I have a rather naive question: Why do you recommend "the Economist" as oppose to something like the HBR?

noir-york 10y ago
I've read the Economist for the last 20 years and the HBR for a few months before I dropped it. The Economist offers insight, thoughtful analysis and writes about the world: literally but also politics, culture, and science. The obituary is surprisingly fascinating for instance. You may not always agree with its position, but you know that their position will be worth engaging with and thinking about. No, I don't work for the Economist, I just appreciate thoughtful articles. Same goes for Private Eye, Foreign Affairs, New Yorker.
- danieltillett 10y ago
  The best obituaries are in the Telegraph. I am still angry they have put them all behind a paywall :(
  - noir-york 10y ago
    Aha interesting! Never read their obits. I find Evans-Pritchard a good read.

Patrick_Devine 10y ago

Did you ever consider partnering with a larger vendor? Figuring out the right GTM is tough, and the timing was weird, but GOOG and MSFT must have been pretty desperate for a NoSQL solution 2013-2014 to compete with DynamoDB. Firebase got scooped up in October 2014, but it wasn't until April 2015 when Azure announced DocumentDB.

v3ss0n 10y ago

Sorry i am the one who leaked . @coffeemug we greatly appreciate your effort and rethinkDB is well architectured database in existance. We gonna keep using it and contribute to Rethinkdb .

patates 10y ago

It seems like you have a great ability to self-evaluate. Many of my friends and I, after reading your post, agree that we would be very willing to work in a team managed by people like you.

danieltillett 10y ago

While I feel for you because failure hurts so much, congratulations on learning from your experience. I know this won't make you feel any better, but the next time you try things will be so much easier. By the way the tone is fine given your experience.

atis 10y ago

Thanks for all your work. I understand that you're waiting for a legal framework to accept donations as an organization, but there was an article recently about an individual GIMP developer being funded on patreon. Is this something you would consider? I'd be happy to contribute to someone who's actively working on RethinkDB (of course without any backer rewards or similar expectations), and perhaps others would as well.

martincmartin 10y ago

Thanks for writing this, and writing it with candor. What do you think of Spolsky's "Good software takes 10 years"? https://www.joelonsoftware.com/2001/07/21/good-software-takes-ten-years-get-used-to-it/ https://www.joelonsoftware.com/2001/07/21/good-software-take...

scott_s 10y ago

I hope my finished writing is as good as your draft.