1. 20

  2. 17

    My software work is divided into three camps:

    • Open source work I write for fun or for my own use
    • Open source work I write to better the state of the art
    • Code I write for my employer

    I get paid for the third one, obviously. The first one I don’t expect to get paid for. I wrote, for example, mtm because I think terminals are neat and wanted to try to write a minimal terminal emulator. It was fun.

    The second category is the kicker though. I have a couple of projects on the back burner that would really potentially enhance the state of the art (mostly dealing with high-speed pattern matching, and another dealing with relational algebra as a data exploration tool). Those projects are fun, sure, but they would likely be used by real people for real things. Real people using them for real things means that if they break, Bad Things happen. I’ve had enough experience with Open Source to know that if Bad Things happen I’m going to get yelled at and begged to fix the problem…but probably not paid.

    So not paying for Open Source software hasn’t stopped me from writing it, it’s just stopped me from writing/releasing some really good stuff…

    (That first project I mentioned above, the high-speed pattern matching thing, ended up getting sponsored by my employer and might actually see the light of day one day, so I suppose that’s good.)

    1. 11

      I wonder how much of the issue is people being unwilling to pay versus people being unwilling to go through the effort of paying. Probably more the former, but if the latter has an impact, there might be ways of addressing that too. Maybe something like the Spotify model, where you donate 5 dollars a month and it’s split among many different projects?

      1. 5

        where you donate 5 dollars a month and it’s split among many different projects?

        And then you have effectively https://www.patreon.com/

        1. 7

          You kinda do, but the model of Patreon is to donate a significant sum to a specific recipient, while this model would be a chosen sum split across several receivers. I imagine it would be easier to only commit $5-10 a month knowing that all the projects you enjoy will get a small sum from you rather than choosing only one or two projects you want to support the most.

          1. 7

            So, exactly like Flattr.

            1. 3

              That does indeed look exactly like what I would want embraced in the FOSS community. It seems difficult to find creators to support via their page, so the creators would have to promote their presence on Flattr on their project pages.

              I would imagine this is the kind of thing that the GitHub sponsor system could employ to great effect as well. GitHub is already fairly well trusted (inb4 zomg M$!) and many developers already have a relationship to the platform.

        2. 3

          This sounds like a good idea actually, but what would be the difference between subscribing to a service like that versus setting up a recurring donation to your favorite projects?

          1. 7

            I only have to do it once, as opposed to for every project I want to donate to. Also it can have sensible defaults, where important transitive dependencies also get money.

            1. 3

              Automatically donating to dependencies is a very interesting concept!

              1. 4

                Yeah it is! Seems like subscribing to a service that takes $5 each month, and trawls my dev directory tree to figure out who to send it to would be super useful.

                1. 1

                  Problem is that as soon as something like that takes off, all your dependencies are going to start changing in an effort to game the system.

                  1. 1

                    Not sure what you mean? Who is it who has the motivation to game anything and how would they do it?

                    1. 1

                      Once there’s money involved, everybody has motivation to game it, and how they’ll game it depends on how it works. The only surety is that it’ll happen.

        3. 6

          In all honesty, Fritzing is pretty subpar software in general.

          It starts the user out with a breadboard-like view of “schematics” which is extremely counterproductive. Users should be taught how to draw proper schematics. All too often people will post breadboard screenshots from Fritzing on various electronics forums and will ask for help with their circuit, and almost always the response is, “draw a real schematic, and then we’ll help you” because nobody wants to try to decipher Fritzing’s breadboard views.

          Looking through their getting started page

          “The schematic view instantly shows the circuit you built in breadboard view as a circuit diagram, and is handy for those of you who are used to or wish to learn about standard circuit symbols.”

          Learning schematics is not optional if you want to make anything meaningful with electronics. Just like you can’t say you have a programming environment where the primary programming interface is Scratch, but it automatically generates something like Javascript and says it’s there for those who “wish to learn about Javascript” and also say that full-featured software should be made with the system.

          It makes no sense.

          Then when it mentions the PCB view (which they write as “pcb view” for some reason…)

          “The pcb view features an Autoroute function, which is a great time saver.”

          Again, just going to lead to users making badly routed boards because autorouters are almost invariably terrible unless you know how to use them. Making a schematic and clicking autoroute is not going to go well. Sure it might work, but your board will look ugly and it will be absolutely obvious to anyone who looks at your board that you had no idea what you were doing. Learn to route boards by hand. It’s not hard to make really nice looking boards once you know a few guidelines. There’s no reason that software meant for creating relatively simple circuits like Fritzing is should have an “autoroute” function front-and-center.

          1. 5

            I agree with you that Fritzing is not the ideal tool to get started. Our university uses it to get started on drawing schematics, and I wanted to write a simple guide for our students to explain how to go from creating these horrible Fritzing schematics to creating schematics in Kicad which are actually usable.

            To create this guide, I needed Fritzing to draw my examples, using exactly the problems you just described, like autorouting. This was when I discovered what Fritzing was doing.

            1. 4

              That’s great that you’re doing that! Thank you for helping teach people how to actually learn electronics design and not rely on horrible crutches that hold them back. KiCad is my EDA software of choice and it’s super satisfying to draw up a project with a really nice schematic and routing a board by hand and making it look pretty.

              Those students will definitely appreciate learning how to do things properly!

              1. 4

                Thank you! I really appreciate the motivational words and we share a common love for well designed schematics! :)

                Edit: So I’ve been reading your blog and we also share a common love for hating Arduinos in production.

                1. 3

                  So I’ve been reading your blog and we also share a common love for hating Arduinos in production.

                  Oh goodness yes.

                  Arduinos are not a microcontroller! They’re a devboard!

                  I find them incredibly valuable for development, but once I really get a project hashed out, I quickly start building up a schematic with the individual parts on a custom PCB. I also despise the whole putting an Arduino on header pins to make it part of a final board.

              2. 2

                I would love to see your guides. I just installed Kicad 5.1 inspired by your post.

                1. 2

                  It isn’t a guide yet, but I’ve written an actually an extended rant about Fritzing: https://bowero.nl/blog/2019/11/13/the-right-tool-for-the-job-designing-schematics/

                  I’m glad to see you on the right track! I’ll give you an update when the guide’s finished.

                  1. 2

                    Thank you! That is absolutely terrific.

                    I understand that some mistakes were intentionally introduced, but there were a few that I do assume were errors. For instance, the following paragraph appears twice:

                    This is still relatively easy to use. It doesn’t look very neat, but it’s easy to build on this drawing. However, the problem is already becoming visible. Imagine if we were to add five more motors to our robot:

                    If you would like me to proofread it when you are nearing completion I would be happy to.

                    1. 2

                      Thank you very much! You are obviously correct, that should not have been there twice.

            2. -5

              That developer that thinks he deserved something for his work on opensource is wrong. Either don’t release it as open source or STFU and accept the consequences.

              1. 10

                I think we can agree that asking for donations in a user-hostile way is wrong, and expecting people to pay for your project could be wrong, but at the same time, there’s nothing really wrong with asking for contributions from the community if they feel it’s worth it to them. I’ve donated to quite a few open source projects (especially open source android apps) and acting like devs should “STFU and accept the consequences” is pretty selfish.

                1. 4

                  I agree with you that developers never deserve anything, but I do understand that developers of big projects would like to get some sort of compensation.

                  If you actively maintain a linter that is being used by thousands of developers each day, that is something different to me than some silly project of you that you decided to throw on Github for the commit history. The latter doesn’t deserve shit, but the first one definitely deserves something. The question is who will have to pay for that.

                  1. 4

                    Even the linter example, they knew that if they open sourced it, they can not expect anything back. Yes they can want to, but they have no right. If they expect something back, they either didn’t understand what could happen, or they have mismatched expectations. Open sourcing something means you don’t deserve anything in return. Yes, it’s nice to get something in return, but if you expect it, that’s not how it works.

                    1. 7

                      Then we need to also accept that it’s ok for developers to tell the users to STFU when they abandon their projects. For some reason, much fewer people are advocating that point of view.

                  2. 4

                    Heavens forbid somebody is asking for a small amount of money in return for the countless hours they spent on the project. Countless hours that in turn may have saved others even more hours.

                    That aside, telling people to “STFU” or just not release their code is not very productive, and frankly immature.

                    1. 1

                      Big +1. You know what you’re getting into if you decide to do open source code.