The Value of Open Source

I've written extensively about open-source software before, mainly here, here, and here. It came up again at GDevCon NA. There were 2 back to back presentations about open source tools, followed by the 7x7s, where many of the presentations were about open source tools that the presenters had developed.

How Making a Tool Open Source Helps To Improve It

We often think of open source as a contribution to the community. There is another side to this. Making your tool open source allows the community to contribute to your tool. Enrique Noe Arias gave a presentation about how, by making his Panther Dashboard open source, he got all kinds of ideas for new features from the community. These new ideas made his Panther Dashboard even more useful. So both the community and Enrique benefitted from making his tool open source.

Open-Source Tools As Opportunities For Learning And Inspiration

When it comes to using open source tools, we often think simply about the problem the tool helps us solve. For example, we need to talk to a specific database and so we find an open source driver to talk to that specific database and use that so that we don't have to reinvent the wheel. That is a great use case for open source.

If we look at our open source tools as simply solutions to specific problems, we're missing out on something. Not only does an open source tool solve a specific problem, but it also presents an opportunity for learning and inspiration. Because the source is open when we need to talk to a different database we can look at that source code to learn how the author solved particular challenges and use it to inspire us as to what is possible and provide new ideas for what features we should implement. Dan Press gave a great presentation on some of the things he's learned by diving into the code behind various open source tools and how he has used that knowledge to solve new challenges.

Mental Barriers To Open Source

There are some technical barriers to creating, maintaining, and using open source projects in LabVIEW. Jim Kring talks about some of them, such as compatibility between various LabVIEW versions. There are also mental barriers. They fall into 2 categories.

Developers Who Are Reluctant To Make Their Tools Open Source

Sometimes developers are reluctant to make their own tools open source. There are a variety of reasons for this. Let's look at a few.

• My tool isn't good enough. A tool doesn't have to be perfect to be useful. If it is useful to you, there is a good chance it will be useful to someone else.
• I don't want to take the time to polish it up. Yes adding that last little bit of documentation and polishing does take some effort, but generally, that pays off because it helps you as well. It makes the tool easier to use for everyone including yourself. If it feels like too much of a burden, see the point above. Code doesn't have to be super-polished to be useful. By making your code open source you are also empowering the community to help you with those last polishing steps.
• Releasing it is too much work, or I don't know how. VIPM.io and the community version of VIPM have made releasing packages much easier. You no longer have to jump through all the hoops put up by the LabVIEW Tools Network. You don't even have to as far as releasing a package on VIPM. I do encourage that, because it really isn't that hard, yet you can simply make your GitLab or GitHub public and stop there.
• If I make my project open source, then I'll have to maintain it. As a counterpoint, you are probably already maintaining that code anyway. By making the code open source you are enabling the community to help you maintain it. If a user finds a bug they are empowered to fix it, not just for themselves but also for you and all the rest of your users. If a particular user is too demanding, you can always respond by offering to give them their money back.
• If I make my code public, then I am giving away my secret sauce. What makes you special isn't the code you write. It is you. It is the way you think and work with others to solve problems. There may be some things that are worth keeping secret, but in general, most of the code you write is not that secret. Most of the code you write is solving general problems, that have been solved by plenty of other people already. Also if you are a consultant, open source code works great as advertising. Plenty of LabVIEW programmers know of JKI, Delacor, Hampelsoft, and many others because of their open source projects.

Developers Who Are Reluctance To Use Open Source Code In Their Projects

Some developers are reluctant to use open source code in their projects for a variety of reasons. We'll dive into those shortly, but first I want to make two points. Point one is that you can still learn from open source code without actually using in a project. You can just clone the repository and check out what the author is doing and use that as an opportunity for learning and inspiration. There are plenty of open source utility tools that you can use to improve your IDE experience without actually including any open source code in what you ship.

As far as not wanting to include open source code in what you ship, here are some common reasons why people hesitate:

• I don't like dependencies in general. You are not alone. There are plenty of people who agree with you. I've written about this before. The trick is to balance being overly dependent on other people's code with not reinventing the wheel. Being critical about what dependencies you include is actually prudent.
• How do I know someone is going to maintain this? All code needs maintenance, not just open source code. No software vendor guarantees that they will fix every bug you find. Just because you find a bug in Windows does not guarantee Microsoft will fix it. If they decide not to, the chances of you being able to fix it on your own are pretty slim, since you don't have access to the source code. However, if you are using an open source tool, you always have the opportunity to fix bugs yourself, if the maintainer decides not to or is unable to.
• How do I know the quality of this tool? That is a good question. The answer is easy - go look! Often this question is just an excuse for NIHS - Not Invented Here Syndrom
• I am unsure of the licensing/usage requirements. This is a valid concern. You should be aware of licensing requirements. Some like the GPL-style licenses can be rather onerous, but the MIT and BSD licenses are pretty mild and shouldn't present any real issues.
• I found a tool I like, but it doesn't do exactly what I want. There are several easy answers to this question. You can start by filing an issue with the project and see if the maintainer can add the feature you want. If the maintainer is too busy, you can add the feature yourself and create a Pull Request. As a last resort, if the maintainer doesn't approve your pull request, you can always maintain your own fork. Yes, that isn't necessarily easy, but it is often easier than completely reinventing the wheel.