WiringPi Library To Be Deprecated

Since the release of the original Raspberry Pi single board computer, the WiringPi library by [Gordon] has been the easy way to interface with the GPIO and peripherals – such as I2C and SPI – on the Broadcom SoCs which power these platforms. Unfortunately, [Gordon] is now deprecating the library, choosing to move on rather than deal with a community which he no longer recognizes.

Among the points which he lists are the (commercial) abuse of his code, and the increasing amount of emails and messages on social media from folk who either failed to read the friendly manual, or are simply rude and inconsiderate. As [Gordon] puts it, WiringPi was never meant to be statically linked into code, nor to be used with anything other than C and RTB BASIC programmers. He never supported the use of the library with other languages, or having it statically integrated into some Java/JavaScript/NodeJS project.

As this secondary use is what’s draining the fun out of the project, he has decided to put out one final release, before making it a closed-source project, for use by himself and presumably paying clients. What the impact of this will be has to be seen. Perhaps a new fork will become the new ‘WiringPi’?

Suffice it to say, none of this is a good thing. The illegal use of open source code and the support nightmare that gets poured on the authors of said code by less than informed users is enough to drive anyone away from putting their projects out there. Fighting abuse and junking the ‘spam’ is one way to deal with it, but who has the time and energy (and money) for this?

What are your thoughts on this news, and this issue in general? How should an open source developer deal with it?

Thanks to [Dirk-Jan Faber] for sending this one in.

60 thoughts on “WiringPi Library To Be Deprecated

  1. It’s somewhat sad to see Gordon going up on this project, but I don’t think it leaves a critical hole.

    It’s more disturbing to see the reasons he’s feeling the need to give up on it. The kind of people he’s complaining about are literally the “reason we can’t have nice things”.

    I’ve occasionally used WiringPI, but more often, I’ve used PERL and the BCM2835 PERL module from CPAN.

    There are also comparable bindings/libraries for Python for those that prefer that.

    What concerns me is that it may well be the case that both the PERL and Python libraries make use of WiringPI under the hood. If that’s the case, then this might be a bigger issue.

    1. My takeaway from his blogpost is that WiringPi became this core piece of infrastructure on millions of units around the world, and that’s not something he thought he was signing up for when he wrote it.

      Supporting a core piece of infrastructure is a lot of thankless work. Everybody blames you when stuff breaks, even when it’s not your fault. Nobody thanks you when it works right 99.9% of the time. Can’t blame him for not wanting to do that, especially for free.

    2. I actually think Gordon, may be one of the ‘we cannot have nice things people’ too. Move on. Stop the look-at-me drama and realize if you give something away for free it is out of your hands beyond that. No sympathy here.

      1. It’s Gordon’s code. He agreed to give it away for free, not support it for free, and improve it for free. People are literally shipping boards and software with his email as the support email. Your lack of empathy is definitely part of the problem, not him.

    1. From the blog post:

      “I never intended for wiringPi to be statically linked either – and thanks to the incompetence of many people who have done just this, I’ve had over 10,000 emails from people who upgraded their Pi and found that code stopped working because they were reliant on a system (typically some java/javascript/node or home automation or UPS thing) which had statically linked an older version.”

      So basically if it’s statically linked, it breaks, and then people contact him instead of going to the people who statically linked it in the first place.

      1. 10,000 emails? I don’t blame him a bit for wanting out of that!

        Thanks [Gordon]. You did a good job, putting WiringPi out – you don’t owe anyone a thing, especially the people you mention.

        I hope you get some joy out of your next project.
        DaveSSI

    2. The problem with statically linking it comes when someone doesn’t know how to do that, tries and fails (or doesn’t bother trying), then goes and complains how that failing of theirs is the fault of the software author.. Well, ya can’t bite the hand that gives you free stuff and not expect a negative outcome.

      It seems the sheer number of such people doing exactly that was more than Gordon wanted to put up with.
      That such people exist and do that kind of thing at all is just sad. But anyone having to deal with them is going to have their own tolerance levels before saying enough is enough.

    3. Incompetent clowns, selling junk products, break via updates, Gordon’s contact details are displayed. Queue vast emails from users, or entitled shits making demands. It’s all in TFA

  2. I don’t think the WiringPi library is still needed. Linux gpio/spio/i2c/… support for the BCM platform is complete, you can just use the normal kernel interfaces. Has the advantage of also working on many other SBCs, especially if you use named interfaces in your device tree.

    1. The problem is that that requires understanding what you are doing. Most Pi tutorials that I’ve seen make me shake my head. They promote a lot of wrong ways of doing things when there are better, easier, safer and more future safe ways.

      I don’t think the people complaining and causing the issues here are competent developers, but the “I can hack something together” people.

    2. Even though its not necessarily needed, its been baked into so many other products and the people who make those products haven’t bothered to update their own product to reflect the kernel changes (or made it possible/user friendly to update their product). They’ve pretty much left it so that they’re dependent on Wiring Pi to change for them for their product’s continued use. Deprecating it is the logical conclusion in this case, basically telling those product developer/designers that they need to update their product and design it better in future.

      Developers should know that all products (whether software or hardware) will require updates for continued use (nothing is static these days) and that if they base some part of it on another person’s code (I understand its easier than reinventing the wheel) that dependency is a risk they must try to avoid/mitigate against, especially if that code is written by a single person – that’s a HUGE risk.

  3. i was already starting to have problems with the library when writing my i2c controller drivers. ended up having to use bcm2835.h and twowire.h instead. couldn’t get any sensible data out of my controller with wiringpi.

    1. i should point out i was aware of the forthcoming deprecation and figured it was better to move on than to try and figure out why it wasn’t working. i had done a simple proof of concept controller with an attiny85 (2 axis+button), and a working driver in my code folder while it sat for a couple years pending the construction of a better controller. so it was entirely my fault, i didn’t even bother gordon about it.

  4. I would echo the sentiment… those kind of parasites are the reason we can’t have nice things.
    Play nice or GTFO. And take your mongrel projects with you.
    What people like Gordon are, are the shining stars of FOSS.
    What they are not is the 24/365 support for newbies and people who are too lazy to do their own research.

    I for one would appreciate that companies, and individuals realise just how the GPL and other licenses work – they are NOT a free-for-all, where you can nick other people’s code and pretend it’s your own.

    I’ve been working on a project myself recently, for a friend and it uses a fair bit of GPL licensed code, on the pi, in fact.
    The guy who wrote it is a diamond. I’ve been grateful for his support, even to the extent where I’ve apologised to him for contacting him when I’ve had issues. I’ve never been rude, abusive, or demanding, and he’s never once told me to go away.
    If people continue to treat these people the way they have treated Gordon, then there will be no-one left who is willing to release their code as opensource, let alone support it.

    Some of the best software in the world is FOSS now (LibreOffice, GIMP(glimpse?), Blender) and a lot of people have started to take notice of it and, even big business is taking it more seriously these days.

    1. “how the GPL and other licenses work – they are NOT a free-for-all, where you can nick other people’s code and pretend it’s your own”

      According to http://wiringpi.com/download-and-install/
      WiringPi is released under the GNU Lesser Public License version 3.

      From the article Gordon never meant for WiringPi to be
      1) commercially abused (e.g. commercial abuse of his code)
      2) statically linked into code / integrated into some Java/JavaScript/NodeJS project
      3) used with anything other than C and RTB BASIC programmers.
      4) used as a library with other languages

      The GNU GPL does not forbade or restrict users (thus preventing them from doing any of that), users
      can basically do whatever they want with the code (including making money off it) as long as the GNU GPL license is included and they honor the requirements of the GPL.

      Honestly, it sounds to me like what Gordon wanted was a non-free license (eg. closed-source) that allowed them to
      dictate the exact manner in which someone could use the code (commercial or personal-use, etc)……the key word is non-free, meaning not GNU GPL.

      The spirit of the GNU GPL is to implicitly give “freedoms” to the end-users to do what they want with the code, without the author being able to place restrictions on it.

      The decision made by the author to place code under the GPL is an acknowledgement that they are ok with those “freedoms”…..this is an issue authors need to consider before GPL’ing code.

      1. That is all very well. But neither does the GNU GPL license require the licensor to do anything more than allow the code to be used. End-users are “free” to do what they want with it, and to handle any issues that arise from such use.

      2. You seem to be concentrating on what the GPL allows users to do with the code, rather than what the author can do with the code.
        And one thing that the author absolutely can do with the code is walk away from it and stop supporting it.

      3. you don’t understand. Yes, they are free to do so. But when they do so, then they should do it and don’t bother the author when it not works like wanted. But they demand a solution for things he never planned and wanted to suppport.

      4. What he licensed users to do by choosing the LGPL and what he “intended” users to do is not necessarily the same thing.

        This is from the page you linked to and I think sums it up well;
        “Also note: WiringPi is developed and tested on a Raspberry Pi ONLY. It is for C and RTB BASIC programs on. If you are trying to install it on anything else, then good luck.”

        He doesn’t forbid users from doing other things with it. He says “good luck” as in it isn’t going to be easy and he is not going to hold their hands through the process nor consider how not to break what hacks they might have implemented in doing so when designing future updates.

        And yet it would seem that many people doing these things emailed him with an expectation of support as though it was owed to them. That’s the problem right there and there is nothing about the LGPL which says he has to accept it.

      1. He gave the code, not the support. Can’t blame him for closing the source code of the newer version when shitty IoT vendors appropriates the code, mess it all up and leave HIS email address as the contact if shit goes wrong.

    2. Did you offer ££?
      Better still , did you ask if they have paypal/whatever and just force some $$ at them?

      Probably not?
      There’s your problem
      ‘He’s a nice bloke, gave up his time to support me personally so I said nice things about him’ doesn’t pay the bills
      Money does

  5. It is a sad story for Gordon.

    I work as Level3 support engineer for a commercial Product myself, and had never a problem to tell customers “that is not supported” when needed (providing workarounds where possible). Maybe that is not so easy in Open source.

    I used mostly “gpio” command line command from WirinPi, and that will still work.

    For µs resolution waveforms in C and with “pigs” command line tool I have switched to Joan’s pigpio library completely months ago for Rasspberry v1 camera global external shutter work:
    https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter#requirements

      1. Seems like a perfectly good opportunity to introduce a pay for support site and then get paid to solve these issues. As long as the fee is reasonable, there is no reason for him to not be paid to solve such issues. If every one of those 10000 support emails asked for $1 then the situation is starting to look quite positive. ofcourse Gordon may just want to do something else with his time – fair enough. Just saying.

  6. There’s a difference between “the FOSS movement” and “the free riders”, and this event highlights the issue.

    Participants in FOSS contribute to the projects they use in terms of development, resources, useful bug reports, documentation, or just understanding the system and answering questions. The free riders don’t.

    FOSS has an enormous capacity to carry free riders, as long as carrying them is also free. The problems start when the free riders start to consume resources (especially the time and attention of actual participants). People who consume resources but don’t deliver anything useful back to a project, by definition, cost more than they’re worth. If they accumulate, it’s only a matter of time before something collapses under the load.

    In this case, it was Gordon’s willingness to keep putting up with the demand.

    And since I’d estimate the number of actual FOSS participants in WiringPi to be much, much smaller than the number of free riders who cost more than tney’re worth, I doubt anyone will pick up the project and keep it going.

    For those of us who move in the FOSS/OHW world, there are a couple of lessons to take away:

    First, we just need to be aware of the difference between participants and free riders, especially with regard to the code and hardware we use. Nobody can participate meaingfully in everything, but we need to be aware of the times we’re riding for free. Good FOSS/OHW manners include remembering that we have no right to demand more from a project than we’ve paid into it.

    Second, we need to recongnize that FOSS and OHW are just like restaurants, art, and web design in the sense that doing them for ‘exposure’ is a joke that stopped being funny a long time ago. Tens of thousands of people using on WiringPi didn’t make the project stronger or better. They killed it. The ‘exposure’ they provided was mostly toxic. The act of riding free is never a positive contribution. At best it’s a minor nuisance, and at worst it’s a nuisance whose severity scales with adoption.

  7. I don’t understand why more open source devs who’s code is being used in violation of the license (especially those like this guy who are annoyed about such use) don’t use copyright law and go after those who are violating said license.

    In fact there seems to be less interest in pursuing license violations now than there used to be and large companies who should know better continue to not publish source code, publish incomplete/incorrect source code or take months or even longer after the release of the binaries before they finally publish source code (I dont know if its gotten better recently but last I checked many Android vendors didn’t publish the correct kernel source or only published it months after the binaries were released and sometimes only after lots of pressure from the community)

    1. More often than not, pursuing license violations costs a lot of money. If you’re maintaining open source code, you’re not usually in it to make tons of money. This is why people think it’s fine to violate licenses, there’s literally zero comeback.

      1. pursuing license violations in court will also put your day job at risk. most tech HR will consider you a major security risk once it is known that you pursue legal action. they will be asking “will this guy turn is in for a minor license violation?”

    2. It’s expensive and risky to pursue large companies who do this sort of thing. They have very large legal departments and deep war chests. You’re not going to be able to get them to stop with a cease and desist letter that you paid a few hundred bucks for. You’re going to have to bring suit against them, and that carries it’s own risks. Discovery is a two way street, and it’s an ugly process. Most people would rather not have a small army of lawyers crawling through all their data trying to find a way to discredit them.

    3. With regards to commercial exploitation, maybe it’s time for an organization similar to EFF, or a business (eg a law firm) to provide a low-cost copyright management service for FOSS projects when requested. This could be paid-for by the recovered fees and damages.

      For the doofuses (doofii?) who rag on a FOSS maintainer when a leeching product or project stops working, probably the best approach is a big upfront disclaimer and then ignoring or dismissing such complaints. It doesn’t always pay to be nice.

      1. You mean like this?

        15. Disclaimer of Warranty.

        THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

        16. Limitation of Liability.

        IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

        https://opensource.org/licenses/gpl-3.0.html (which the LGPLv3 explicitly inherits)

  8. At this time, the ‘mike stone’ comment is the most accurate. Colleagues and denizens of the various venues that I hang out on have oft asked why I never put my stuff on github or my web site (dark to the public for almost 10 years). This is why. Humans, as a species and at the societal level, are destructive and self-serving. As I have said on this and other forums, your good deeds will be punished.

    Many are thankful and respectful of the people that publish the good stuff, but the deprecation and retraction of important projects will become more common. The risk/reward ratio for open stuff has become less than one.

  9. You need to accept that any time you publish Open Source code then it is a life sentence.
    And the better and more popular your code is, the worse the punishment.

    I was in email communication today with someone about a hardware driver that he wrote in 2005 and hasn’t used himself since. (But that is in the context of me picking up the support burden, but without the hardware to test with)

  10. The real issue here that I see is that RPI should have had a GPIO library to start with. They are the real culprit here. If you make a device have the sources and updates to go along with it.

  11. I use open source software everyday, but this sort of things comes with the territory and I saw it coming years ago when it started to become a big deal in the media.

    As soon as you share source code, schematics or project notes for anything – Unless you have an entire team of international lawyers specialized in IP law and all the money to pay them on hand, you should really expect this sort of thing. You either want your work to be free to everyone, including those who might try to make a buck off of it or not – Or you should really be ready to sue someone – and good luck with that when it goes international.

    I don’t share much of anything for any of my designs or projects. I made it for me to enjoy, not for some bozo somewhere to copy and sell and slap their name on it OR totally wreck it and then leave the blame at my feet.

    I have total respect for those who want to do this sort of thing for the greater good and the fact I get something out of it, but i don’t pity anyone who doesn’t see the bad sides of doing it…

  12. So…don’t support people? How hard is it to not respond to an email? When I opensource something, it comes with the caveat of use it at your own risk. If you want support, maybe I’ll feel generous but more likely: pay me. If I got too many emails asking for help in a capacity I had explicitly outlined as not supported, I’d filter and delete them.

    I give my code and designs away for free because they do no good sitting on my workbench laptop. If it’s out there, it helps somebody. If they break the opensource license…well, they’re jerks. If those jerks use it in a way that’s critical to their business, they’re still jerks. I’d go about my day the same as I do knowing that most of Congress is jerks. Which is to say, happily.

  13. The lesson I take away from this is;

    – When starting an open source project consider from the start that it may grow larger than intended
    – Therefore only ever do so anonymously
    – Do not give out an email address, instead set up a forum and an IRC channel.
    – Direct users to the above in TFM, help files, menus, etc…

    Hopefully if the project grows beyond what you can support yourself, so will the community of other helpful people answering questions on the forum. and/or chat

    And if not?

    F’em! They aren’t paying you and you don’t owe them a thing!

  14. In other news, a programmer has a fit over not understanding the implications of giving up his IP for free. “They made money off it!” Welcome to the real world….Back to academia for you.

  15. Is he upset that people were making money off of it?

    I didn’t gather that from the article but people seem to be implying it in the comments.

    I thought the problem he had with the “commercial use” was that they were statically linking it in to a closed source project (not sharing the source code) and then directing people to complain to him when being closed source and hard coded these products were incompatible with updates as though it were his problem.

    I have no sympathy for someone who releases “open source” only to feel cheated and offended when someone makes a buck off of it. Oh boo hoo! If you wanted to sell it yourself you should have closed it from the start and sold it yourself! If you just wanted to make it available to help others well, it is doing that. Be happy! Just because someone is paying their rent while they help distribute your contribution doesn’t mean that everyone else can’t keep using it for free just like you intended. If they were actually following the GPL then they might even contribute something back some day making the impact of your own contribution that much better!

    Non-Commercial licenses are a cancer on the open source community and their use should be discouraged.

  16. With traditional PC’s in a business setting it is often said that the cost of the software on the PC dwarfs the cost of the PC. That is the PC is worth significantly less than the software that resides on it.

    Open source sort of changed this, and a lot of big hardware companies have done well by open sourcing things that work with their hardware, which in turn helps them sell more hardware.

    The problem creeps in with these small platforms where they almost require software written by other people to be useful, and he pi’s original objective was for people to make use of the GPIO, I think a lot of the small computer on a board uses that make zero use of the GPIO were a pleasant surprise but somewhat outside of what the initial focus of them was. Anyway, IMHO, the good folks behind the pi should have been kicking some subsidy back to the small people who wrote pieces pretty much necessary to use their products.

    I guess now it will be if you wanna use the GOIO pins and not re-invent the wheel on your own you can fork over some cash yourself. I can appreciate this, but it is sad that this man helped to sell millions of these little computers and got noting out of it but frustration.

    My apologies if he has been subsidized along the way…

  17. Thanks to Gordon for his WiringPi library and diligent and timely updates for newer architecture. Is wrong he got trolled but surprised that one slobbering twat would cause frustration. Should have gotten thousands of those by now.

  18. If you’re sick of maintaining an open source project, why not just look for another maintainer – or even better: multiple? That’s what open source is all about – it doesn’t have to be a one man show.

    I totally understand the reasons and it is indeed annoying to get so many complaints. Though he would be free to simply ignore them! There is no support requirement at all. I’m also pretty sure that others would have stepped in at a much earlier point if he’d let them.

    I just think “abandoning” rather than declaring it “deprecated” would have been better, leaving it open for someone else to pick it up. Now we’ll get the whole confusion of multiple forks and deciding which fork is the best one :)

  19. It’s a shame to see the WiringPi library be deprecated. It was a very well written library and was critical to the RPI ecosystem, especially in the early days.

    Having said that, the last open sourced version of WiringPi can easily be forked and maintained by someone else.

    I personally have always preferred to wrote my own code. I developed my own C++ classes for doing sysfs GPIO, I2C and SPI. Also developed c++ classes for GPIO and PWM (one pin only) access by “mmaping into /dev/mem”.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.