1. 43
  1. 33

    TextMate and Transmit being “better than anything apt-get could give me” sounds rather amusing, considering that both vim and emacs have exploded in popularity in the last decade by taking in lots of those TextMate users :) And TextMate 2 is GPL, haha.

    Some programmers use proprietary software, sure. Outside of game dev though they more often than not absolutely despise it.

    The number one practical problem with using closed proprietary software is that you’re literally going back to basically where Stallman started – with that printer driver that he couldn’t just fix because it was closed.

    doing open source because that’s what we want to do, what we’re reinforced in doing, all the while invoking generalized, thoroughly hypothetical “users” to lend importance and nobility to our hobbies, compulsions, and fancies.

    I generally don’t think that much about users when working on hobby projects and don’t care about nobility. My projects are open source just because why the hell would I keep them to myself? They would just go to waste there and probably be lost forever. The public is the best backup/preservation system there is. If I helped someone by doing that, well, that’s just a nice bonus to me, not the goal.

    1. 22

      My reference to better-than-apt referred to that earlier time, when TextMate was hot new stuff. The day I bought my license, there wasn’t any comparable substitute in open source. And certainly nothing like the filesystem-based integration with Transit.

      Folks cloned the snippet system for Vim and Emacs pretty quickly, at least partway. But that wasn’t really even half the TextMate proposition. It was just the most visible bit, from the screencasts. It took a long time before anyone really went after the bundle system, the configuration flow, the UI, and the command namespace. When they did, they actually maintained TextMate bundle compatibility—direct clone. Eventually, Atom. More or less a GitHub founder’s pet project, so I’m told.

      I’m back on Debian now. UltiSnips for Vim, in the terminal. But the kind of work I do has changed. And it’s been 17 years. If Allan Odgaard had kept up pace with new ideas, rather than diverting into a big, HURD-style rewrite, I wonder where editors would be today.

      I think it’s fair to set games somewhat apart as its own world. It’s not really the same industry. Ditto film. But my experience doesn’t track yours beyond that. People despise bad software. Despite the hype, open ain’t always better. Mako Hill had a good bit on that.

      As for what people despise, I wouldn’t take that as any indication. Twitter’s full of folks venting about open source, too. Especially when they’re made to use it. That’s not to draw any equivalence. It’s just to say samples of grousing don’t tell us much.

      The Stallman printer story is canon. But I don’t think that makes it real. Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add. They want to call somebody who knows the system, who’s committed to deliver. Or, failing that, drive-by some GitHub repo with a #feature issue, and miraculously see it closed by a PR on the double.

      For good, closed software done right, the end user experience is actually better. You ask, someone capable responds. No one calls you a noob, tells you RTFM, or throws the work to open a pull request back on you. The work gets done by the person best positioned to do it. The experience of the software honors the value of your time.

      I have more than a thousand GitHub repos, and have publicly referred to the platform as a shellmound. I’m not sure my random doodle repos counts as open source, for any meaningful sense of the term. GitHub don’t even insist on a license for free storage, as long as you’re comfortable hanging your laundry in public.

      1. 17

        The Stallman printer story is canon. But I don’t think that makes it real. Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add.

        Counterpoint: For a developer or company with little money, which has been the case for the better part of my career (notably excluding my few years at Microsoft), if they want a feature, fix, or integration for an open-source dependency, they can make it happen given enough time, effort, and skill, but with a closed-source dependency, they’re stuck, unless perhaps they’re good at reverse engineering. That’s a big reason why I prefer open source for libraries, unless there just isn’t a good open-source solution for the problem at hand (e.g. speech synthesis or optical character recognition). Maybe I’m better than most at diving into an unfamiliar codebase and bending it to my will. I find it entirely plausible that Stallman was, or would have been, good at that too.

        1. 8

          Arguably, the possible spaces of software and the way it was interacted with and written were smaller, so Stallman probably would have been good at it. He was a systems programmer, in a systems programming environment, who wanted to hack on a systems progam/driver/firmware.

          That doesn’t necessarily mean that most or even all developers can or should be able to say, step out of systems programming and instantly know how to fix a React bug that is plaguing them. Software is more diverse and more specific, and programming systems are more layered and orientated towards the problem, and out of that comes subfields that are non-transferrable even if some of the basic concepts are.

          1. 10

            I think the problem Stallman faced was that it was illegal to fix the driver. You technically don’t have to have knowledge to fix a React problem, it’s enough you can find someone who can and is allowed to (for payment, if need be).

            FLOSS development doesn’t have to be a net drain on money. The FSF’s standard answer is “support and training”, and that’s fine as far as it goes, but it’s really hard to realize in an age where a project without good docs seldom gets traction and many developers choose burnout handling issues rather than asking for money.

        2. 8

          As for what people despise, I wouldn’t take that as any indication. … The Stallman printer story is canon. But I don’t think that makes it real. Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add.

          I think that, for folks who agree with these points, this makes sense and contextualizes the rest of the post. But not everybody will agree with this. Personally, I have written a Free Software driver in anger, regretting my hardware purchase and petitioning the vendor for documentation. It was a choice made not just from ability, but from desperation.

          For good, closed software done right, the end user experience is actually better.

          And for bad closed software done wrong? It can destroy hardware and hide malware, just to pick on one particularly rude vendor. Note that I would not be able to publish this sort of code in the Free Software ecosystem and convince people to use it, because folks would complain that the software doesn’t provide any functionality to the users. And this is a foundational weakness of proprietary software vendors: they are incentivized to make harmful software experiences due to privileged legal status. (Or, to be blunt: if I published this sort of malware, I would be arrested and jailed for crimes.)

          1. 4

            Haven’t done any real systems hacking in a long while. I did when I was young, and had more time. I definitely had to do some driver and firmware work, to get Linux working with various things. I’m not sure if I was angry going into those projects, but I remember being pretty frustrated coming out of them!

            A lot of that came about from buying cheap hardware. I remember one Acer laptop in particular, the one I chose for college: great specs, great price, terrible build quality, total bodge-job, component- and firmware-wise. I eventually bought the MacBook, and came back to Linux on ThinkPads. I pay a premium for ThinkPads, but I get what I pay for, Linux hardware support very much included. It makes way more sense than spending hours brushing up and hacking patches.

            As for bad proprietary software: oh yeah, it’s out there. But the idea that software vendors have some inherently privileged legal position doesn’t fly. They have copyright, and can require customers to buy licenses. But the terms of those licenses can and do vary. I have advised on several software license deals, for substantial money, on terms that basically boiled down to Apache 2.0 plus a payment clause, limited to just the paying customer.

            If all you’re doing is buying licenses on take-it-or-leave-it terms, or negotiating with highly aggressive companies much bigger than yours, yeah, you’re likely to see terms that strongly favor the vendor. That’s how leverage works. But proprietary software sales get done on sane, fair terms all the time. Perpetual licenses. Modification rights. Meaningful warranties. Accountable maintenance commitments. Sometimes the less impressive product wins out, because the terms offered for it are better.

          2. 7

            Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add

            I think that is observably untrue, given the massive number of extensions available for all of the popular editors, for platforms such as GitHub, or even MS Office. The key point to remember is that being able to modify the behaviour of a program does not necessarily depend on its source being available. Somewhat counter-intuitively, it’s often easier in proprietary programs because they’re forced to maintain (and document) stable interfaces for third-party extensions, whereas open source projects can often just tell people to go and hack on the source directly. Specifically on editors, Vim, Emacs, and VS Code all have extension ecosystems that are significantly larger than the core product, which exist because people who were missing a feature decided to dive into an unfamiliar ecosystem and add it. VS Code and Emacs both did well by making that system less unfamiliar to their early userbase by building it on top of a language (Lisp, TypeScript) that this audience used.

          3. 22

            considering that both vim and emacs have exploded in popularity in the last decade by taking in lots of those TextMate users :) And TextMate 2 is GPL, haha.

            Some programmers use proprietary software, sure. Outside of game dev though they more often than not absolutely despise it.

            Get out of your bubble. Outside that bubble a lot of developers use JetBrains IDEs or Visual Studio. Visual Studio Code has gained a lot of traction in recent years, but initially mostly because Code was much better for web development than the competition and it is free. Not because it is open source [1].

            In the most recent Stack Overflow developer survey, Visual Studio Code is used by 71.07% of developers, Visual Studio by 32.92%, IntelliJ by 29.69%. The most popular fully (?) open source editor is actually Notepad++ with 29,09%. And vim takes the next place at 24,82%, but I wouldn’t be surprised that is because people use vim when doing quick edits remote Linux machines. Emacs dangles somewhere at the bottom of the list with only 5,25%, surpassed by many proprietary applications like Xcode, PyCharm, or Sublime Text.

            The number one practical problem with using closed proprietary software is that you’re literally going back to basically where Stallman started – with that printer driver that he couldn’t just fix because it was closed.

            I agree that this is a major downside of closed source software. But most people want to fix the things they are working on, not their tools.

            [1] https://underjord.io/the-best-parts-of-visual-studio-code-are-proprietary.html

            1. 10

              proprietary applications like […] PyCharm

              PyCharm/IntelliJ IDEA are Apache2 and most devs use the free software version available at https://github.com/JetBrains/intellij-community

              1. 2

                PyCharm/IntelliJ IDEA are Apache2 and most devs use the free software version

                I have no reason to doubt this, but are you aware of any usage statistics? I’m curious whether “most devs” is more like “just over half” or “over 99%.”

                Anecdotally, every company I’ve worked at where the devs used JetBrains IDEs has paid for the commercial version, but totally willing to believe those companies aren’t typical.

                1. 1

                  From my anecdotal experience, no company has paid for the commercial JetBrains version, even when most of the devs use it. It might very well be a cultural thing.

                  1. 3

                    At the two companies where I used it, we paid for the whole toolbox subscription for every developer who wanted it. Most of us used IDEA Ultimate and one or more of CLion, AppCode or PyCharm Professional. Many of us also used DataGrip.

                    I still maintain a subscription for my consulting work now, too.

                    1. 1

                      Can’t speak for PyCharm particularly but every other flavor of IDE based on IntelliJ, I only know of companies who have paid, be it PHPStorm or more likely Ultimate (if working on many languages).

                2. 5

                  I don’t really disagree with you, but your arguments seem kind of weak.

                  Get out of your bubble.

                  In the most recent Stack Overflow developer survey […]

                  What now? It’s just another bubble.

                  [1] https://underjord.io/the-best-parts-of-visual-studio-code-are-proprietary.html

                  I haven’t ever used any of those “best parts” and never seen anyone using them.

                  1. 2

                    I haven’t ever used any of those “best parts” and never seen anyone using them.

                    I’ve used the remote stuff. That and PlatformIO are the only things that ever cause me to use VS Code over emacs or one of the JetBrains tools.

                    The extension marketplace is proprietary too, and I’d call it one of the best parts of VS Code.

                3. 10

                  Some programmers use proprietary software, sure. Outside of game dev though they more often than not absolutely despise it.

                  I mean, there’s Vivado, and then there’s Visual Studio, just like there’s, I dunno, a steaming, rotten pile of horse shit and then there’s pancakes.

                  There are many bubbles in the tech world and game dev is only one of them. I worked in an embedded shop where the state of Linux was that we had one colleague who tried Fedora and he thought it was like a beta or something because he couldn’t put things on the desktop and, in his own words, he expected some things not to work as well as Windows but that was years away from being useful. The thought of writing code in a text editor after finishing college, where they put you through the ritual of compiling stuff you wrote in vim by writing gcc incantations, seemed about as foreign to these guys as the idea of sailing to America on a steam ship.

                  There are plenty of bubbles where programmers use both kinds of tools, too. Way back when I was doing number crunching, everyone at the lab was using emacs, vim, nedit or notepad, but also Matlab, which everyone hated for various reasons but nowhere near as much as they hated, say, gdb. We worked a lot with another research group at another university where it was the other way around: someone had figured Octave was good enough and they had just one Matlab installation for things Octave really couldn’t do or to port their code, and used the money they saved on Matlab licenses to buy a bunch of Windows and Visual Studio licenses.

                  I don’t have much in the way of numbers here but you shouldn’t take a tweet about Vivado as the standard about what people think about closed source tools. Vivado is successful because it barely works and there are no alternatives that work (for any non-hobbyist definition of “works”) – it’s successful largely by vendor lockdown.

                  1. 4

                    Speaking of bubbles, I have literally not even heard of Vivado before today.

                    1. 3

                      Well, what can I say, not every case of acute horse diarrhea deserves to be famous :-D.

                      But seriously, this is one of the things I love about our work. Vivado is huge. I suspect it’s already old enough that virtually everyone who finishes an EE or CompEng degree has seen it at least once (it’s about ten years old, I think, and it replaces another suite called ISE which was also all sorts of horrible in its own way). It’s very likely that it’s been involved in one way or another in dozens of stories that popped up here on lobste.rs, like stories about RISC-V or cryptography or FPGA implementations of classical systems. And it’s perfectly possible for someone to be an excellent programmer and earn a living writing code and never hear about it. No matter how good you are at anything computer related, there’s always something out there big enough that it’s got tens of thousands of people behind it that you had no idea about.

                      If you keep an open mind, computer engineering will surprise you in all sorts of fresh ways, all the time – not all of them good but oh well. Dogmatism is fun and it feels like you’re right all the time but it’s really fscking boring. I’ve done it and it sucks.

                    2. 1

                      By reputation, another reason Vivado is successful is because all the other FPGA toolchains are reportedly even worse. Don’t get me wrong, Vivado is a tyre fire that segfaults, but the others are apparently even less reliable.

                      e.g. I’ve heard that at some shops, people writing FPGA code targeting competing FPGAs will actually write and debug their entire project on Xilinx FPGAs with Vivado and then port the code to the other toolchain for the originally intended target FPGA.

                      1. 6

                        I’ve done too little real work on Altera’s stuff to have had first-hand experience but from the little I’ve done I can certainly say Quartus sucked at least as much as Vivado back when I last touched it (2015-ish?). Maybe it’s changed in the meantime but somehow I doubt it :-D. I heard Lattice’s stuff is tolerable but I never tried it. I did try Microsemi’s Libero thing though and it makes Vivado feel like Visual frickin’ Studio. Porting designs between toolchains is not quite like porting program code and it sounds like a really bad idea on paper but, indeed, given how bad some of these tools are, I can imagine it’s just the only way to do things productively sometimes.

                        But it’s really a lot more complicated than how good the toolchain is. A big – probably the biggest – reason why Vivado and Quartus are so successful is simply that Xilinx and Altera… well, Intel, are really successful. The next version of Vivado could suck ten times as bad as the current one and it would barely put a dent in their market share, just because it’s what you use to do things with Xilinx’ devices. Developer souls are a lot more fungible than silicon.

                        Also, being so big, they both have roots in the academic world and they run deep, and it’s simply what lots and lots of people learn in school. They’re not very good but as long as the bitstream flows out, who you gonna call?

                        A competitor with better development tools could, in theory, steal a chunk of this market, but that chunk would be exactly as big as how many programmable logic devices they can sell, and there are constraints – both technical (as in, performance) and non-technical – that dictate that long before anyone even considers the quality of development tools. The usual retort is that developer tools are important for productivity. And they are, but the best designs, from the most productive teams, won’t be worth crap if there are no physical devices for them, or if these devices cannot be obtained on time and in the required quantity and at the right price and so on.

                        I also secretely suspect that it’s just a case of the audience of these tools being a little more tolerant to weirdness and poor quality. I mean, they taught me how a transistor works in my second year of uni. I then spent the other half of my undergrad years (and I could’ve spent a whole two years of masters’ on that, too) learning about all the ways in which it doesn’t quite work exactly like that. Software segfaulting under your nose is just a tiny drop of weird shit in a very big bucket of weird shit which people way smarter than you reverse-engineered out of nature. Your entire job revolves around manipulating all sorts of weird but inevitable things. So you just learn to chalk up the fact that Vivado crashes if you have more than 64 mux instances whose names start with the letter X under “inevitable” [1], somewhere between “all P-N junctions have leakage current” and “gate capacitance varies with gate oxide thickness”. What’s one more?

                        [1] Note that this is something I just made up on the spot but it does sound like something Vivado would do…

                        1. 2

                          A competitor with better development tools could, in theory, steal a chunk of this market, but that chunk would be exactly as big as how many programmable logic devices they can sell

                          You don’t exactly need to sell programmable logic devices to steal a chunk of FPGA development tool market. Symbiflow has already done that with Lattice’s FPGAs, and are slowly starting to bite into Xilinx FPGAs as well. Quicklogic just released their new FPGA product without their own software, just by giving Symbiflow their bitstream generator and FPGA definitions. There are signs that the new Renesas FPGAs are using Yosys (part of Symbiflow) too.

                          The reason why these closed software tools are so entrenched is that they are tied in with hardware. And as of now, open source hardware is a lot more niche thing, than open source software. With time, that will probably change, but even then, the software landscape in places dealing with hardware will progress faster. Just remember, how a while ago working on microcontrollers almost always meant dealing with vendor-specific IDEs. That is basically gone now. With time, that will happen with most FPGAs as well.

                          1. 1

                            I haven’t tried Symbiflow since 2020 and it’s a project I’m really cheering for, so I’m not going to say anything bad or unenthusiastic about it. But it’s worth keeping in mind that the iCE40 line (the only one that it supports well enough to be usable for real life-ish projects) has a very straightforward, wrinkle-free architecture that lends itself easily to reverse-engineering. Even though the underlying technology is physically the same, as in, it’s based on the same technology (FPGA), the market Symbiflow can realistically target is practically different from the one where people are using Vivado and complaining about it. Its relative success in this field is important and useful, not to mention liberating to a lot of people (including yours truly) but I wouldn’t be too quick to generalize it.

                            This approach will probably find some success at the low-power, low-cost end of the spectrum, where not only are customers rather unwilling to pay the licensing costs, but some companies, especially fabless vendors like Quicklogic, would be reasonably happy to be rid of software development cost. But this part of the FPGA market works in entirely different ways than the part of the FPGA market that’s bringing the big bucks for Xilinx (and Altera) and where the people who associate the word Vivado with an overwhelming feeling of dread work. For one, it’s not a field where architecture and fabrication technology are important competitive advantages, so there’s not that much value in keeping it closed and keeping the software tied to it.

                    3. 11

                      Some programmers use proprietary software, sure. Outside of game dev though they more often than not absolutely despise it.

                      I don’t know, I would far rather use Visual Studio than i.e. whatever editor + gdb again.

                      1. 6

                        You’re right that systems programmers and hardware devs prefer small and lean tools, which are often released as open source, but walk into any corporate dev house and you’ll see a lot of Visual Studio and IntelliJ with Xcode and other IDEs sparkled in. The sole exception to this are web devs, whose first usable tool was VScode.

                        If you have the skills and time to hack on your tools, open source is better, but for most people it’s just a better proposition to pay someone else for their tools and use the saved time to do their job and make that money.

                        1. 4

                          Actually most devs use proprietary software, and kemitchell even mentions this in the post. He switched to Mac, but Windows is still the most popular platform even amongst devs[1]. I suspect the Stack Overflow survey results are even skewed and that Linux likely has less market share than they found.

                          https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-operating-system

                          1. 2

                            I hope I made the point that devs do use proprietary software. It’s not true that devs just won’t use closed code. But I don’t have data to support the claim that most devs do. I suppose you could get there by arguing Windows and OS X are closed, and the number of folks on Linux is small. I’ve enjoyed looking at the Stack Overflow survey, but I have no idea how representative that is.

                            For what it’s worth, when it comes to laptops and desktops, I’m back on Linux again. I did switch to Mac when I was younger. And I did my programming career that way, before going to law school.

                            1. 1

                              I have a trifecta! I have a Linux laptop (which I used when I first joined the company to do development), a Mac laptop (which I also do development on) and a Windows laptop (because our Corporate Overlords are Windows only) that I don’t use, and can’t return (I’ve asked).

                            2. 2

                              But how much of that is because companies require Windows? When I was hired at my current company, half the employees used Macs (mostly developers) and the other half Windows. We then got bought out by an “enterprise” company, and they use Windows exclusively. They even sent me a Windows laptop to use, even though I use a Mac. The Windows laptop sits unpowered and unused, only to be turned on when I’m reminded that I have to update the damn thing.

                          2. 21

                            I use proprietary software for work. It has great features, like forcibly mangling SHIFT-JIS comments into Window-1252 with no way to change my encoding. Or features like bizarre, fucked up proprietary file formats that are impossible to diff with git unless you pay $250, per head, per year, for their “git integration” license. Or really, really cool features like making breaking changes every sub-release of the ide/language, and then recommending that you use a VM to keep your old version around because they also couldn’t figure out how to let you use choose which version you wanted.

                            I would rather not use proprietary software for development.

                            1. 3

                              So there’s no open-source replacement for this software?

                              If there is, and your employer doesn’t want to use it, how about trying to find a new job that does?

                              1. 6

                                No, there isn’t any open source tooling in industrial automation. Most factories have a set of PLCs they bought in the 90s, and you need to buy that brand’s IDE to do work on that machine. So mitsu PLCs require you to hunt down a copy of GX Developer (and you better hope said copy is a Japanese one if you’re working in a Japanese plant or else you’re fucked), wago PLCs require their ide, and so on.

                                1. 1

                                  opcfoundation.org ?

                                  1. 2

                                    OPC mostly encompasses data sharing from PLC to PLC or PLC to scada system, right? And typically, most factories use the proprietary system: MELSECNET for Mitsu machines, can’t remember what the other ones are called. There is a standard for languages that a PLC should support: IEC 61131-3, but not every manufacturer follows the standard.

                            2. 13

                              I’m the author of the article that Mr. Mitchell is responding to.

                              tl;dr: I think Mr. Mitchell has good points, but I also feel like he did not address the parts of my post that actually discouraged me.

                              I didn’t expect to have anyone respond with a blog post like this. That said, Mr. Mitchell has some good points.

                              First, he is right that my original article is too absolutist. I will own that mistake. Please remember, however, that the post was written in the middle of a depressive episode, when I was feeling more discouraged than I had been in a long time. I wasn’t thinking completely straight.

                              Second, he makes a good point about trying hard to serve people, but what he missed is that I had done that. In the types of software I want to write, I could see very well that closed source was not going to fly with my intended audience. @alexandria said (in this thread):

                              People will only pay for closed source software if they can’t already acquire a ‘good enough’ alternative for free.

                              As far as build systems and version control systems go (the top two projects I am working on), there are plenty of ‘good enough’ alternatives that are Open Source, so developers only want Open Source, for the most part. Of course, there are companies that will use closed source, if it is better, but individual developers, by and large, don’t, especially because they often don’t need the features that make the closed source ones better.

                              The reason I am targeting individual developers is because they are the most likely to be “early adopters” of new technology. I was hoping that, after getting enough of them as users, they would convince their employers to start using my software.

                              Third, and this follows from the previous point, Mr. Mitchell has himself said that, over time, software moves from closed source to Open Source, then to public domain. I had read that post of his before posting mine, and I understood what he was saying. I guess what I did not say well is that, for the software I was planning to write, the transition from closed source to Open Source has already happened, which means that going closed source would not work.

                              Fourth, I don’t feel like Mr. Mitchell addressed the points from my original post that actually made me discouraged: the appropriation of Open Source by companies who fail to give back or outright steal (by violating FOSS licenses). Those things are the reason I was discouraged because, even if I do get individual programmers to use my software, then they get their employers to use it, what will prevent their employers from just ripping me off and violating the license I put on my code?

                              The fact that developers will use closed source in some cases, as Mr. Mitchell says, does nothing to address these problems.

                              With that said, I don’t regret putting that post out and submitting it here and to the orange site, and that’s because my “call to action” at the bottom, asking people to contact me if they knew things that could encourage me, worked. A lot of people emailed me with encouragement, and that eventually brought me out of my funk.

                              One person in particular, who I won’t name in case he does not want to be named, wrote to me about an article he wrote a long time ago about how it’s possible to make a living selling closed source software that is only closed source temporarily before being open sourced after a certain amount of time. He helped me see why that works, and he also helped me figure out a method for not violating my ethics in doing so.

                              (My ethics include always providing source code to my users, like an architect should provide blueprints to the owner of the building they designed. What this person helped me realize is that even if it’s closed source, I can provide source code to my customers with a license that prevents them from redistributing it. Yes, this is an argument for copyright still applying to software.)

                              That, along with Mr. Mitchell’s assertion that all software eventually moves toward the public domain, helped me form a plan.

                              First, I’m going to get the software ready, of course. But when it’s ready, I’m going to release it under the terms of the two most radioactive licenses possible: the SSPL and the AGPL, and users will have to comply with the terms of both. This shouldn’t matter for individual developers.

                              However, it will matter to companies, so next, I will do my best to make sure my users know that they can ask me to relicense more permissively once they are asking their employers to use my software. When they ask, I will.

                              I will also develop closed source add-ons that companies can use, and these add-ons will be open sourced after a certain period.

                              In essence, my software will follow the transition from closed source to copyleft to permissive licensing that Mr. Mitchell described; it’s just that instead of more permissively-licensed competitors rising up and out-competing me, I’ll relicense my stuff to prevent the need for competitors to do so.

                              That does beg the question of why I wouldn’t start permissively licensed in the first place, and the answer is to make my software radioactive enough that at least some companies won’t touch it at the beginning. It’s a game of numbers because I don’t have to prevent all companies from ripping me off, just enough of them. And after my software grows more important (if that ever happens), then I suspect that companies would be less likely to rip me off, even if the software is permissively licensed.

                              It’s funny, but Mr. Mitchell did help me, in a way, with his post about the lifecycle of software licenses.

                              1. 8

                                Forgive me for catching up with you here! I’d made a note to send you an e-mail, properly, which I try to do whenever I blog a response to someone else’s post. But Saturday caught up with me. I got the post out, and didn’t look at my to-dos again until this morning.

                                Note to self: Publish the post, then send the e-mail. Don’t put it off!

                                I hear you on discouragement and depression. Man is that real, and I’m inspired by how honest and open you are about it. I wish I’d thought more about where you may have been mentally as I wrote, and done more to emphasize a helpful rather than corrective tone. If I’d caught you still in it, and come across too harsh—easy to read that way when you’re down, don’t I know it!—I could have done you wrong. I’m happy to read that my post found you standing firmer on your feet. I just got lucky there. Also that others stepped up with so much encouragement. A little faith in community restored.

                                As for company and user misbehavior: oh yeah, that’s real. And I’m really fucking tired of it. And I’m probably doing disservice by taking it as a given, whenever I write. By focusing just on the jump from frustration to resignation, without honoring the frustration to begin with, my post falls short of a complete picture. Your notes there are very well taken.

                                On licensing, I’d encourage you to consider a license choice that more clearly expresses your intentions. A mad-science hybrid of AGPL and SSPL will definitely freak people out. But if what you really want to say is “businesses needs to talk to me about a deal”, you might find that better expressed through a noncommercial license like PolyForm Noncommercial or Prosperity, which also allows free trials. More experimentally, you might find Big Time interesting.

                                Whichever way you go, good luck!

                                PS: No need for “Mr. Mitchell”, unless you prefer that way. Kyle, or kemitchell, do me fine. And kyle@kemitchell.com anytime.

                                1. 2

                                  First, I’m going to get the software ready, of course. But when it’s ready, I’m going to release it under the terms of the two most radioactive licenses possible: the SSPL and the AGPL, and users will have to comply with the terms of both. This shouldn’t matter for individual developers.

                                  However, it will matter to companies, so next, I will do my best to make sure my users know that they can ask me to relicense more permissively once they are asking their employers to use my software. When they ask, I will.

                                  That depends a lot on the company. I’d have to check our policy but I believe it means that we could use it, we could maintain our internal fork, but we’d need to jump through approval hoops to contribute anything back. Licenses like the AGPL are problematic if we want to incorporate them into a product or ship them to customers (or, in general, do anything that involves the code leaving the company) but they are fine for use.

                                  The critical thing for a company (which I’d assume @kemitchell knows, since he is a corporate lawyer and this is literally his day job) is minimising risk. The license is one aspect of this. Dual licensing doesn’t really help here because it lets you choose between risks (the risk the supplier will go away for the proprietary license versus the risks associated with a less permissive license). If your dual license allows people to pay for a more permissive license (e.g. MIT) then you now have a risk that someone will distribute the version that they receive.

                                  For a single developer, the largest risk that a company is likely to worry about is the bus factor. If you get hit by a bus, what happens to the software? That’s a massive risk for anything that’s going to be a core part of the work flow. There’s a big difference between buying a proprietary product from a big company and a proprietary product from some guy, especially if it’s a product with a lot of users and that is bringing in a lot of revenue.

                                  Open vs closed is one of the less important concerns within an overall risk discussion for most companies.

                                  1. 2

                                    That depends a lot on the company. I’d have to check our policy but I believe it means that we could use it, we could maintain our internal fork, but we’d need to jump through approval hoops to contribute anything back. Licenses like the AGPL are problematic if we want to incorporate them into a product or ship them to customers (or, in general, do anything that involves the code leaving the company) but they are fine for use.

                                    That actually sounds perfect, to be honest, including not giving back code. I’m interested in companies contributing back in general, but for my own purposes, I’d rather not incorporate code copyrighted by Microsoft into my repo.

                                    That said, I don’t really like the SSPL and will probably remove the requirement for it soonish after the code is published.

                                    The critical thing for a company (which I’d assume @kemitchell knows, since he is a corporate lawyer and this is literally his day job) is minimising risk. The license is one aspect of this.

                                    I think I understand the position companies have on risk, and I want to do my best to make risk minimization the real product I am selling.

                                    Dual licensing doesn’t really help here because it lets you choose between risks (the risk the supplier will go away for the proprietary license versus the risks associated with a less permissive license). If your dual license allows people to pay for a more permissive license (e.g. MIT) then you now have a risk that someone will distribute the version that they receive.

                                    Those risks are partially why I’m not going to dual license the core.

                                    For a single developer, the largest risk that a company is likely to worry about is the bus factor. If you get hit by a bus, what happens to the software? That’s a massive risk for anything that’s going to be a core part of the work flow.

                                    Yes, I agree, and it is a weakness of what I would like to do. But I do have some techniques for reducing the impact of the risk from the bus factor.

                                    First, I document my code heavily. You can see this with my bc especially. The development manual in bc is the largest file, by far, in that repo. But I didn’t stop there. I commented every piece of code heavily so that someone else could go in, follow what I was doing, and be able to understand it. This reduces the impact of the bus factor by making it so users can have the backup plan of fixing bugs themselves if I get hit by a bus, and that backup plan has a chance of working.

                                    Second, I create extensive test suites. Once again, bc is the example. The test suite is so extensive that I feel comfortable making massive experimental changes and just running the test suite (usually under Valgrind or ASan) to see if there was any regression. Should I get hit by a bus, the test suite then becomes a tool for anyone else wanting to make changes to do so without fear, just like me, which I believe reduces the impact of the bus factor.

                                    Third, companies can pay for the privilege of making the time factor a non-issue, and by “time factor,” I mean the possibility that I don’t have enough time or motivation to respond to their bug reports in a timely manner. But that’s the risk that they themselves have to mitigate; I can’t help with that.

                                    There’s a big difference between buying a proprietary product from a big company and a proprietary product from some guy, especially if it’s a product with a lot of users and that is bringing in a lot of revenue.

                                    I agree. In fact, it’s why I am doing all of the stuff I mentioned above. Doing those sorts of things brings a one-man project closer to a product from a big company. I think it’s why a project like Curl, which basically has a bus factor near 1, is so successful and widely used.

                                    Sorry, said to much, but tl;dr, you are right about risk, I know you are right, and I’m doing my best to mitigate that.

                                    1. 3

                                      I’d also add that risk and perceived risk are both important. It sounds as if the risk is low but I’m not sure what to suggest for reducing the perceived risk. A company has to do a lot of analysis of your code to understand how difficult it would be for someone to take over but that’s probably more work than most companies would do. You might be able to do some equivalent of underwriting: have some other company like Red Hat or Canonical provide maintenance contracts that they subcontract to you.

                                      With curl, the reason that the risk is low is that, to a first approximation, everybody depends on curl. This means that, if Daniel were hit by a bus then everyone is equally screwed. If you are not the biggest company depending on curl then you can depend on someone else leading the effort to pick up maintenance costs.

                                2. 11

                                  Someone wise once told me “it’s a poor craftsperson that blames their tools.”

                                  1. 7

                                    This has always bugged me as a saying because a good craftsman maintains his tools well and picks the right tool for the job. The underlying assumption in the saying is that you are using tools that you chose and that you had the option of selecting better tools.

                                    1. 1

                                      I dug into the history of the saying a while back and it’s originally something like “a poor craftsman has bad tools”, so more in line with what you said than how we use it now.

                                  2. 10

                                    It’s all a matter of value provided. If you create a solution to a previously unsolved high-value problem, then devs (or companies employing them) will use it and buy it.

                                    A lot of tools have been commoditized, and their OSS status is just freeware/freemium model. If you’re writing just a make clone, its value is even negative: solves a problem that can be solved for free, but costs a new thing to install and learn.

                                    OTOH if you somehow manage to write a build system that takes down compile times from hours to minutes, you can sell it literally for millions of dollars.

                                    1. 6

                                      Programmers use software in various shades of “closed” all the time. It’s not hard to find companies selling proprietary tools, libraries, frameworks, and other components galore, if you’re willing to look on Google, and not just on public GitHub, npm, crates.io, RubyGems, &c. College students, hobbyists, and unfunded startup types who pay for their laptops and stop paying there represent a small, transient sliver of the trade.

                                      Look in video games. Computer-aided drafting. 3D printing. Computer numerical control. Throw a rock.

                                      Exactly, Dragon Ruby is a good example of this, IMHO

                                      Since my software will target programmers, I can’t make it closed source, or it won’t get used. Simple as that.

                                      Objectively false. Unless your software—in Gavin’s case, a new build tool—just isn’t that much better than make. To literally anyone.

                                      And this is the crux of the thing, and the entire flaw with the original article about closed source software. People will only pay for closed source software if they can’t already acquire a ‘good enough’ alternative for free.

                                      The Make(1) example is well-put, I think LibreOffice/OpenOffice grew from the same effect, most people had used Microsoft in a business environment, however it was not free, so the closest free alternative was Libreoffice. Look at cancel and his “Ripcord” Discord client, for an example of how his closed source software took off on a small scale, but was quickly outclassed in market by “BetterDiscord”, which provides many of the same features for free, as a simple Javascript layer over the existing Discord client (The Ripcord Discord server has 464 people, whereas BetterDiscord’s Discord server has 82 thousand).

                                      To most users, it really doesn’t matter how open the software is, cost versus features is a harder hurdle to jump.

                                      1. 5

                                        Look at cancel and his “Ripcord” Discord client, for an example of how his closed source software took off on a small scale, but was quickly outclassed in market by “BetterDiscord”, which provides many of the same features for free, as a simple Javascript layer over the existing Discord client (The Ripcord Discord server has 464 people, whereas BetterDiscord’s Discord server has 82 thousand).

                                        To be fair, I think Ripcord is inherently a lot more niche than BetterDiscord, even if the free/proprietary side was swapped there. A replacement client for a specific kind of taste is gonna be a lot smaller than a do-everything bolt-on for the thing you already use.

                                        1. 3

                                          Also, in this specific case there is significant market pressure in the form of Discord banning people for using non-official clients, which heavily favors the JS plugin approach.

                                      2. 0

                                        If you look hard enough, you’ll likely find some dev that uses closed software.

                                        Thus it’s not a completely false statement.