Open source software projects are making huge contributions around the world. They allow communities to pool their resources and achieve progress that couldn’t be reached by individual teams in silos.

While there are open source projects in LabVIEW, it feels like a resource that we aren’t great at using as a community. Every project I’ve seen seems to handle things quite differently, and it can be hard to track down where to work. Since I started the first draft for this post it seems there have been discussions in the US on the same topic:

In this post (and another on setting up a project). I want to collate what appear to be best practices in other communities to see if we can’t improve the open source capabilities in our community. There are hundreds of guides out there – so I will be liberally linking to others and trying to highlight the potential differences in LabVIEW.

Open Source Project Structure

So what is an open source project?

In short, it is a project that someone has decided to make available for free to everyone to use and improve. I’m not advocating making all of your work free, but often, there are bits of sawdust – the bits of code or tools that you have lying around to make you more effective, that you can share and help drive the community forward.

Firstly let’s look at the people involved in a project:

  • Maintainers – Normally the original developer, they are responsible for the master copy of the project. It may also include trusted contributors who have taken on more responsibility. As well as working on the project, this is the group that will be involved in setting a direction for the project as well as assessing and accepting contributions.
  • Contributors – These are people that have provided code changes or documentation to the project.
  • Users – More obvious, people who are using the project themselves and may contribute bug reports and other issues.

Find Projects

There are some tools for finding open source projects to use or work on, but don’t be surprised if LabVIEW is missing from the list.

If you are looking for a project for a specific function, then Google may be the starting point. However, when I tried this with Modbus, the results weren’t great. Adding “open source” to the search got us closer, we now see download pages, but no source code.

So, to do better, we need to search some common places for open source projects to be hosted. We can stick to Google for this. By far the most common for new projects is so we add ( and can be worth trying too). Now we see two open source libraries

Of course, those sites have their search functions which can be useful too.

If you go to and enter “language:LabVIEW” into the search box, it will show you all of the LabVIEW projects on there. You can then add additional search terms to narrow it down.

A big concern with open source is how do you know if this project is reliable? There are a few indicators that you can consider:

  • Most services have some form of user rating – while the small size of the LabVIEW community doesn’t help these – you may be able to apply some judgement to them. For example, projects can be “starred” on GitHub.
  • Look at how active the project is. GitHub will show you the latest commit, and you can also see releases, commits and contributors at the top. If there is a good commit history or multiple contributors, this is a good sign the project is active which usually means a higher quality output (since maintainers are fixing bugs or improving the code base).
  • Finally, it is open source! Download the code and examples and take a look to see what you think, try it out quickly before committing to it.

Use and Report Issues

The simplest thing you can do to support a project is using it! From the GitHub page you should be able to find directions to install the project and possibly directions on reporting issues.

I try and will be convincing others to do the same, to use the built-in issue tracker on GitHub or bitbucket. This means that:

  • The issues and discussions are public so others can contribute.
  • When you have an issue, you can search this first and see if there is an existing solution. (yay for reduced support burden!)
  • The issues list becomes a list of items that new contributors can work on.

When you find a problem or something you want to change, the first thing to do is create an issue. This allows you to open a dialogue with the project maintainers about the problem. They may already have a fix, or they may suggest you contribute the change yourself.

Fix Issues and Contribute

Firstly, contributions don’t have to be code. I was delighted on the LabVIEW CLI project to have help producing a getting started guide. Maintainers sometimes leave documentation and examples to the end but they are hugely valuable. Of course, you can also contribute to the code base as well.

A good project should have a contributing guide in the repository. This will let you know how the maintainers want to receive contributions. This is also a great place for details on things like LabVIEW version, source code structure or build instructions.

If ther is no contributing guidelines, there are some excellent guides for this already, so I’m not going to repeat them here:

  • A good general description:
  • A LabVIEW specific guide to Github (covers starting from scratch):

Further Reading

I hope this article gets you interested in contributing to open source in LabVIEW. If you wanted some more comprehensive guides then I suggest the following:

  • First Timers Only – A guide for those who haven’t contributed to open source before.
  • Open Source Guides – A comprehensive set of guides for open source. The link here is to their contributing section.

But most of all – starting using a project today and let the developers know what you think!

The post Open Source LabVIEW – How To Contribute appeared first on Wiresmith Technology Developers.


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *