> Imagine the carpenters were like programmers. You bought a chair.
Except no carpenters ever gives out chairs for free let alone thousands and millions of them for free. And then they get abused for making a shoddy chair even though sometimes it is the best thing available in the market for free.
There is an amazing video editing program for Linux called shotcut. Absolutely and 100% free. It may not be finished but The commercial version of it on Windows costs anything from hundreds to thousands of dollars per month yet this is the comment I came across from a person today(1):
> It’s even named SHOTCUT so similar to SHORTCUT. The only reason i stay with it is because i only know how to edit on it. @shotcut, if you are reading this, i hope you have a bad day.
I've read similar comments on vlc, audacity, etc. The amount of complaints and lack of appreciation of OSS projects is absolutely mind boggling to me, yet we keep getting new amazing software for free.
>I've read similar comments on vlc, audacity, etc. The amount of complaints and lack of appreciation of OSS projects is absolutely mind boggling to me, yet we keep getting new amazing software for free.
I find the worst is with OSS projects that are intended to replace professional software. Software that costs hundreds or thousands of dollars.
Gimp, shotcut(and other video editors), libreCAD, libreoffice, OSM, Ardour, inkscape, Krita, even linux itself.
I've seen some of the most vitriolic and nitpicky comments towards that and other similar software, over sometimes the stupidest things like ui differences to the commercial equivalents or something equally as shallow.
Myself, I'm just happy there's so much professional quality open source software. It may not have the bells and whistles of the fairly expensive commercial equivalents, but compared to only 15 years ago or so, the amount of software these days that will let you do professional quality work at home completely free is incredible to me and the quality of OSS offerings keep getting better, while in a lot of cases, the commercial versions seem to have focused almost entirely on converting as many of their products to services as possible.
If they are intended to replace professional software, there is a reasonable expectation that it can actually do just that. I'm thankful that there are some really amazing open source projects that allow many people access to applications capable of producing professional results "for free" (while being "free"). They are fighting an uphill battle with less resources for the "professional" users, though.
> I find the worst is with OSS projects that are intended to replace professional software. Software that costs hundreds or thousands of dollars.
The price of software isn't ever really going to be a consideration when it comes to software that is supposed to be "professional." Obviously when you have direction and strong incentives (make more money) products tend to gain capabilities and polish at a rate that an uncompensated OSS project can't match. But none of that matters to someone trying to edit a video or score a soundtrack or create illustrations or whatever else they're trying to do with their "professional" software.
> I've seen some of the most vitriolic and nitpicky comments towards that and other similar software, over sometimes the stupidest things like ui differences to the commercial equivalents or something equally as shallow.
Except user interface is extremely important for professional software. You are committing a lot of time to learning the way around an application that is extremely complex. This is why people get stuck on a particular digital audio workstation or nonlinear editor versus another. There is an extremely steep learning curve to switch. Free software should be trying to lower the barrier to entry which means replicating user interfaces of popular commercial software. UI differences aren't stupid, they're really important, especially for software that you're expected to be using day in and out every day.
> Myself, I'm just happy there's so much professional quality open source software.
I'm also thankful for it. Not everyone is a professional who can afford the high prices of commercial software and having access to such powerful tools for free is incredible. When I was a kid I pirated a lot of software. Macromedia Dreamweaver and Photoshop were really important to me at the time but nowadays exploring interests is much easier (and safer).
I'll readily admit that in certain fields (particularly programming, but also programming-adjacent ones) open source software is good enough and arguably better than commercial offerings. In those cases yeah, people are going to maybe have discussions on the merits of using the free software over the commercial closed-source ones. That's how it should be. That's not how it is for a lot of creative fields, though.
These things are being made by people mostly for free. I know there's corporate funding and donations amongst bigger projects, but they're being made by people, for free, so that a free alternative to expensive software can exist.
It's one thing to complain about software you pay for negatively.
When I used alphaCAM and Park Industry software I expected to be able to phone them any time and they'd hop on TeamViewer and help me with any and every minor problem, but alphaCAM costs $10,000/year. For that $10,000/year i have every right to complain or ask for any bit of customer service I want, for $0/Ever, I can deal with it, make a polite suggestion and hope for the best, or submit a patch.
You'd be surprised how little most people think about this. People outside the programming bubble just google programs and install them. For them there is no difference between open source, freeware, shareware etc. They have a task, they look for a free-as-in-beer software and then have an opinion on its quality. They have zero idea of how software is made or financed. For all they know or care, it could just fall out of the sky or grow on trees.
Perhaps projects should include a "don't be an asshole" addendum to their license of choice that allows revocation in cases of abuse by users. It's a small thing to ask, but I'm not sure I like 2nd order and higher consequences of such an addendum.
But man, it would probably feel great to reply as @shotcut, "Your license to use shotcut has been revoked under section 8.3.4 of the license agreement. Please cease use of shotcut until remedies under section 8.3.4 have been made (public written apology for abusive behavior)".
I'm sorry you had to handle that, but it's the nature of the world that some people are uncaring ingrates. Don't fixate on them. Most people do appreciate the work and effort.
I honestly think Shotcut drove Black Magic Design to release a mostly complete free version of Davinci Resolve. It is just so good, that the leader in editing software had to make the tool free to most users.
The “leaders in editing software” are arguably Avid’s Media Composer, Adobe Premiere pro, and Apple’s Final Cut Pro X, none of which have free versions.
The free version of Da Vinci Resolve was released back when it was still a color-correction tool, before it started adding meaningful editing capabilities. So, no, I don’t think Shotcut is relevant.
Consumers who don't know how a software is built, tend to take it for granted, have the attitude like software grows in trees and end up selling their data, soul and future to Big Tech which seems to give them everything 'for free'.
There's a reason why we haven't had successful kickstarter, indegogo like platform for software; People on average just don't want to pay for intangible stuff even if it affects every aspect of their lives.
Finished software has lots of nice properties. What this article gets wrong is that it elevates a situational property of certain software to an imperative. Like so much praise of Unix, it's fetishized.
To be finished, software has to exist in a specific context, for a circumscribed purpose. But some software is inherently open-ended, because the question of how we should work is open-ended. The way we work has changed over the past decades, and the software that supports that work has also changed. IDEs aren't finished, and neither is Emacs. Compilers might have a stable interface, but their internals aren't ever finished (you can artificially freeze the optimizations you do, but you're not done, you're giving up).
Even for the cases the article starts with, I have my doubts. Is grep finished, or is it stagnant? The wow feature of ripgrep is performance, but it also provides new functionality (like ag before it).[0] Grep is finished, but the cludge of pipelines and copied shell snippets that people attach to it aren't. Eventually someone says "instead of find xargs blah, let's write a tool." Finished software makes a decision about shunting the complexity elsewhere.
[0] Amusingly enough, I don't use ripgrep or ff or many other new tools, because I am a creature of habit. But they look like something I _should_ use.
As someone who has shipped some of the biggest products at one of the biggest companies, I don’t think software is “finished” in a manner we ascribe to most products.
I do house projects and have built furniture, and when I “finish” those, there is nothing left to do. There is literally no additional work for those projects I can think of.
I’ve never shipped software that didn’t have bugs we didn’t fix, some feedback that didn’t get addressed, technical debt (test etc.) we didn’t get to, or features we wished we added.
Software is just a different beast to a lot of other things that you “finish”.
Everyone is a creature of habit. So new tools should be tenfold better to kick the habit. Is ripgrep so good? Doubt it, although it’s definitely better.
I use ag wrapped in a shell script interactively. Does exactly what I want with more than enough speed. Been packaged with Debian for a long time as well. Ripgrep doesn’t seem to offer any advantages although could probably find something if I had time.
I would say that grep is finished. Somebody, even the grep developers, may create something better, but it's something else, not grep. Even if it's called grep 4.0, there isn't much that one can change and still have the same software.
Well grep is 47 years old. Still it took many years and many authors to reach a more or less steady state, because PEOPLE CANNOT STOP TINKERING.
This is, by far, the reason software doesn’t get finished.
Keeping some software extremely simple and focused is surprisingly controversial. Everyone in the world wants to add just. One. More. Little. Tweak. What could it hurt? It’s not quite complete without it, right?
What if you never intended to finish? What if you only do it for fun of working on something interesting? Is it then wrong to stop as soon as it stops being fun, and you face "hard" or boring problems?
Let's not pretend that everything needs to be "finished" or monetized. Let's just not kill fun by spreading pressure to "finish" or "get it done".
Sometimes I make a project just to learn something new. Sometimes I make a project just to prove that some crazy idea I had could actually work. Sometimes I make a project in order to reinvent old stuff in a new way that makes more sense to me.
> Let's just not kill fun by spreading pressure to "finish" or "get it done".
Completely agree. I have no idea why people are being shamed for walking away from projects. They aren't paying us, there's no incentive to offset the boring work. There is absolutely no obligation to finish anything. People who don't like that are more than welcome to do it themselves or pay for it.
If people want to spend time finishing and polishing a project, that is absolutely fine. However, it must happen because they wanted to do it, not because they were shamed for not doing it. Nobody has the right to tell people what to do with their valuable time.
What do you think about reframing “walking away” as “done!” or “done for now, no problem if I never get back to it before I die”? Done-enough rather than a nagging presence of unfinished work?
Edit to add: ties in with my reluctance to use “should” with myself or anyone else.
As long as you (a) don't publish your project as open source (i.e., keep it private on GitHub) or (b) put a really big fat warning in the README that it's an experiment that may be abandoned at any time and nobody should rely on it, I guess it's ok... but who really does that?
Publishing a project does not mean you're obligated to maintain it. There is no need to explicitly write this in documentation either. Nobody is obligated to work for free. If people expect to rely on developers, they need to hire them.
I've made a rust implementation of handlebars rendering that passed all handlebars test cases (on the feature set I covered, namely everything that did not involved JS parsing and evaluation), put it in a lib, ran performance checks against other implementation (not stellar, but good enough) documented the design and common API use cases.
Yet, it was not finished in the sense that it relied on third party compiler plugin with dependencies on APIs removed on rust 1.0 release.
That experimental part was 100% what I wanted to play with, I didn't care much of the risk of being stuck in the end.
So, my goals where met, I moved on, and finished depends only on the way you look at it.
I suspect large part of stuff that get started goes stale for more or less the same circumstances: it is finished because the goal was toying from the start, even though the author might have been delusional on publishing a re-usable outcome.
A project doesn't have to be that complicated to be useful. I've coded two utilities. One for converting IPs to their hex representation and back and linking it to various files automatically (for PXE booting), and another for using Mailgun from command line.
Both tools are 2-3 hour jobs, running on production for years, and they meet all the requirements. OTOH, if you want to extend them, you can improve them leaps and bounds and they'd be never finished in my life.
I love this quote from DaVinci: "Art is never finished only abandoned". I also consider software as a form of art (which we can debate if you feel), and in my book, software's never finished, only abandoned.
And, to be honest, I love how software is never finished.
Software can be considered as art from many perspectives IMHO. Some of these perspectives are UI, UX and internal architecture. Smaller parts like API design or implementation of a specific feature can be art in itself though.
In my book, elegance and high quality design is important, however it's expensive. A good architecture needs a lot of work to build and even more work to keep it clean, because software tends to outgrow its design during iterations as it gets more features. This is the prime cause of software rot.
An elegant architecture is easy to program and extend until you outgrow it. An elegant UI is a beauty to look at. An elegant UX has minimal mental load. OTOH, making all three happen at the same time is a very hard task. My experience is on systems side and high performance code. So I focus on architecture and UX. I try to make very performant and complicated applications very easy to use, almost making them too easy to use.
This removes burden from user, it removes friction. The user accomplishes something complicated without much effort, yet the results are precise, accurate and most importantly correct. This is what I consider art. OTOH, I make sure that all custom controls are available to the user if the user needs.
In all cases, developer and user gets joy from developing/using the application. It feels nice rather than a burden. It feels smooth, like an enjoyable road trip where you both enjoy the road and driving at the same time.
The author seems to be suggesting that one can "finish" a project solely by limiting technical scope. But what really allows one to finish is limiting the set of users and use cases. Limiting technical scope is just an indirect way of accomplishing this.
So there's a huge tradeoff between "finishing" and potential impact. I've heard of ZeroMQ. Until today I'd never heard of Libmill.
And that's okay! I'm just saying I don't think it's possible to have a project that both has a large set of users and covers a narrow enough set of functionality that it can be "finished" by a single person.
Great article. While there is definitely some software which needs to continually change by its very nature (think tax preparation software, where the tax laws change a bit each year), probably there are a lot more programs which could become stable and then only receive tiny fixes or tweaks every now and again.
Witness what DeK did with the version numbers of TeX... Instead of counting upwards with the natural numbers, each successive version of TeX receives an added decimal digit appended on the end, which makes it approximate pi more closely. The implication is that the program is asymptotically approaching its final state, after which it will not change.
I think finishing your stuff is a late step in a software engineer's journey. It's appropriate when you feel you've had your fill experiencing the fun of exploration and exhausted the growth you achieve by taking on a technical challenge that's beyond your experience (but not your ability!).
It's the final touch - it proves you can craft something and put it on display, ready for the world to see.
(Of course, there are always bigger technical challenges and new areas to explore. This doesn't apply to them.)
Nothing is finished, always abandoned. Sure, you may have a list of exit criteria, but I can almost guarantee there were ideas you had to FIGHT to not add.
This article seems to complain more about a lack of focus than a lack of completeness - I'm going to go out on a limb and say that maintenance is good. Maintainence keeps software up to date with new tools, old bug fixes, and occasionally new hardware. I like all of this. None of this turns the OP's chair into a table.
And if you have a clearly defined and (from the Unix Philosophy)narrow focus, you'll not transform your chair beyond the original purpose.the If something gets in the way of the narrow focus, you'll revert it. Really, this feels like it derives from do one thing.
I think the value of minimizing updates is in massive and adaptable systems with hundreds of iterating moving parts, not in small UNIX-like tools where the focus naturally restricts the updates.
Absolutely true. You need to finish everything you start (within reason), because starting new projects then quitting becomes akin to an addiction. Don't develop bad habits, start only projects you know you can finish and see them through to the end if you want to be successful.
When I was a teenager I would hop from project to project and rarely finish anything. I wouldn't necessarily say it was an addiction so much as I didn't know any better, and I would quit whenever I encountered a sufficiently challenging technical problem, because at that point the excitement waned, and the project actually became difficult. Then it was easy to get excited by a new project, which, in my head, would be all fun and no stress, until I encountered the next major technical challenge.
In order to break out of that pattern I had to recognize that I had a problem and that this pattern existed in the first place. Nowadays, I usually stick to smaller project with a well-defined scope, avoid starting too many projects, etc.
That being said, as a hobbyist, you have no duty to finish anything. In my opinion, it's OK to reassess your priorities from time to time. If you started something, and it's really become too stressful, you're not really sure where it's going anymore, it's OK to put it on ice and move to something else for a while. It's one thing to keep pushing because you really believe you'll be creating something that adds value to the world, it's another thing to punish yourself because hey, you really have to finish this thing, otherwise you're a quitter.
If you're working on a startup, you definitely don't want to quit, particularly if other people depend on you, but if you already have a full-time coding job, you don't want to burn yourself out working on side-projects, which is unfortunately possible. So you also have to learn to respect and accept your limits IMO.
I’d say that’s a natural part of learning as a kid. You’re exploring and mapping the contours of your environment. I’d argue 100 half finished projects are better than 2-3 finished at a young age.
That's nonsense.
I translate that to "don't ever try to dig into GCC/LLVM/Linux Kernel, because you won't be able to 'finish' it"
There are hundreds projects out there that are worth exploring even one will never 'finish' them, whatever that means
What's the saying, "the last 20 percent takes 80 percent of the time"? That's why people don't finish. Once the fun part is over, they lose interest. The habit to develop is seeing things through that last bit of polishing.
Quitting has its place and what I would avoid is absolutist thinking. You don't need to finish everything that you start. Sometimes you don't even want that as a goal like when exploring or developing prototypes. The only reason that, "only start what you're going to finish" sounds good is because people tend to imagine finishing a project the way they imagined it would be when they started. There is also the story of the person that toils away year after year on a project that probably isn't going to have the outcome they intended. Then again there are people that toil for years that seem hopeless only to make a major breakthrough. There's a lot of uncertainty in the world. No one path is certain.
I think it depends upon what you mean by 'start'. It can be fruitful to experiment with many projects, developing them to the point at which you can make a reasonable judgement as to their value.
You're right that once you seriously commit to a project, you should generally follow it through. But then perhaps that's the problem: people aren't seriously committing to projects, just playing around with them endlessly in a strategic abyss.
I disagree, starting projects that were way too big for me taught me alot about not just the language I was using to develop them, but about best practices, why it is important to have a solid ground to stand on, before adding more features that seem cool. It also taught me the importance of testing, as my projects were getting bigger, more components were interacting with each other, and manual testing soon became way too time consuming.
I started an open source pet project that I thought would take me a few weekends. After a few years, I finally feel like it's "finished". The problem is that I keep having people posting issues on the github project, asking for features that are outside the scope of what I want to do with it. I don't really know a diplomatic way to say no, so I usually just ignore the requests, which itself isn't very polite.
Just my personal take, but be clear about what you don’t intend to “fix” or incorporate. Say it’s not aligned with the project goals and it’s not on the roadmap.
This will help folks evaluating the project better assess how well it fits, and leaves behind a potential feature set for a new project (or fork).
In the long run, not communicating might be worse than a disappointing but clear answer.
This is often a scope problem. In open-source software, or corporate software not-well-managed, it's easy to take on too many features. This can happen by trying to address issues and PRs that should be rejected as out-of-scope. Or saying know to a request from another team, or a customer.
The trend of software engineers starting and not finishing their creative projects has always been interesting to me, as I tend to err in the opposite direction -- for most of my projects, I get this compulsion to carry them to the finish line via as many caffeine-fueled nights as necessary... maybe it's driven in part by sunk-cost fallacy or something (admittedly, in retrospect some of those projects probably weren't worth the extra effort/stress). Still, I find it intriguing how often this other archetype appears.
Priority and motivation can change pretty easily. You can think something is cool and interesting at the start, and then it fades over time. It’s just expectation vs reality, no different than a project car rusting in your garage or an unfinished novel etc
Yeah, it's understandable for sure. Personally though, I find overcoming the technical obstacles and the general process of incrementally crafting a better and more perfect thing to be an addicting cycle.. perhaps reinforced by the fear/knowledge that abandoning a project means capping its potential and locking in all those spent hours at minimal return on investment.
Interestingly, the original Unix philosophy includes the corollary "to do a new job, build afresh rather than complicate old programs by adding new "features."[0]
Hmm, good luck trying this with scrum: Planning meeting for sprint 23. "I think we're done." "How can we be done?" "All agreed-upon features have been implemented." "Aha, but this user story here, that I totally did not pull out of my backside tells a different story."
When I was a teenager I finished a dozen software projects
Closed-source games for Windows 98
It was absolutely perfect. Closed-source, no one comes and complains they cannot compile anymore when the compiler and the library headers change. Games are just done, and if there are bugs they do not really matter. And Windows 98 apps still run perfectly on Linux with WINE.
It's in my HN handle. I stand behind all my posts.
I've got links to a couple of dozen, in there (at least). Maybe over 30. I tend to toss one onto the pile, every now and then. I don't keep count. I don't fork other people's stuff. I'm the original author of all of it. I'm a bit...obsessive. My GH Activity Graph has been solid green, for a few years. I stay busy.
A couple of the projects are sort of "WIP," but you will note that they are also highly polished. A number of repos are legacy repos for shipping apps that have been retired.
I have been shipping software for my entire adult life, and finishing projects is my "at rest" state.
Right now, the other tab in my browser is a Confluence page, describing a project I'm developing (not open-source). It's a slog. I hate writing documentation.
But complete documentation is a big part of "finishing" software.
That project won't be done for months. I'm enhancing the documentation for an API that I wrote (the backend server), so the developer working on the dashboard can get his work done.
Except no carpenters ever gives out chairs for free let alone thousands and millions of them for free. And then they get abused for making a shoddy chair even though sometimes it is the best thing available in the market for free.
There is an amazing video editing program for Linux called shotcut. Absolutely and 100% free. It may not be finished but The commercial version of it on Windows costs anything from hundreds to thousands of dollars per month yet this is the comment I came across from a person today(1):
> It’s even named SHOTCUT so similar to SHORTCUT. The only reason i stay with it is because i only know how to edit on it. @shotcut, if you are reading this, i hope you have a bad day.
I've read similar comments on vlc, audacity, etc. The amount of complaints and lack of appreciation of OSS projects is absolutely mind boggling to me, yet we keep getting new amazing software for free.
(1) https://forum.shotcut.org/t/move-more-clips-at-a-time/10105