industrial software paths
Next Gen measurment
The industrial software paths we considered when creating Red Meters software and our recommendations when planning for your industrial software project.
Hardware + Software = System
As we have mentioned in previous articles, Red Meters are built within an ecosystem of technology. There’s the physical hardware components, the front and back end software and finally the algorithms. Software is often a secondary consideration when creating instrumentation. As usual, we decided to approach things a bit differently than the status quo.
When we first sat down to create the system architecture and determine how we would provide software, there were multiple paths we could take. Below, I’ll share the breakdown of some of the considerations we navigated in order to arrive at the most appropriate method.
Things to Consider
COMPLEXITY – The first consideration was to look at how complex the system might become. Were we trying to build something that others have before or something that is completely unique? Are the functions discrete or very open-ended?
An example of a simple piece of software might be something like a pricing tool to host on your website. A much more complex goal might be an ordering system to be licensed to others that complies with some sort of government regulation.
SCALE – The next consideration was the scale of the product. When contemplating scale, we had to consider not only the MVP (minimum viable product,) but also the full development roadmap. In our case, this was an important consideration as Red Meters has a lot of scaling opportunities as well as an aggressive R&D roadmap.
A small scale project may be building an inventory system for a single store burger bar verus building one for a grocery store with 200 locations
SKILLS – Once complexity and scale were determined, we needed to look at our team and hiring plan. In doing this, we asked ourselves the following questions:
- What are the existing skills of our software teams?
- Do we have enough skills to build our software in the timeline required?
- Should skill gaps be filled by training or hiring?
In some cases, entities may look to outsource skill gaps. In our case, we preferred to keep skills in house.
TARGET AUDIENCE – An often overlooked consideration is the user. A certain level of polish and stability is needed for a consumer focused tool that may not be necessary for internal software designed for a skilled user base. In our case, we saw a significant product gap in modern software for the industrial world. By building software using web based technologies and material design, the user interface could function as a USP for the overall product.
REVENUE MODEL – A final consideration is the revenue model. Some questions you may want to ask yourself are:
- Will you be charging money for this product?
- What method will you use to charge users?
- Are there laws or regulations that restrict what can be done or add difficulty to the task?
- Do you want to accept payment directly or use a funding partner (ie: Squarespace, PayPal, etc.)
In the majority of cases, there are three paths to create software – proprietary, open source and a hybrid of the two. Below I will detail these options.
Proprietary software is typically developed by a single team with little to no involvement or visibility by any other developers or teams. Proprietary software can be created by a development house which is then sold or licensed to other companies to use with their projects. Or, an in-house development team can build proprietary software on behalf of their company.
In most cases, either an entire solution is created for a project, or a company licenses and / or white-labels existing software to use for their project. White-labelling is where an existing software has minor changes to the front end interface to make it look as though it is custom or proprietary software. Often these are simple cosmetic changes such as adding a logo, changing some colors, and in some instances adding or removing features.
Proprietary Software Pros
- Simplicity – as you are paying for the heavy lifting to be done for you, the project should be much simpler to manage from your perspective.
- Ownership – if you purchase an entire proprietary software package from a development house, it should belong to you (assuming you included this in your contract.)
- Support – the development house should be able to provide you with any support, bug fixes, detailed documentation and training.
Proprietary Software Cons
- Limited control / inflexibility – the feature roadmap for a product does not reside with you. In most cases, development houses build for the general use cases rather than your specific needs. The only way to mitigate this is to pay more money.
- Dependency – your software (and thus, product) is dependent on your relationship with the company and the assumption it will stay in business, continue to work with you, maintain the software, etc.
- Opaqueness – on closed software projects, you have limited to no visibility of what’s in the code, whether it has bugs or not, what performance influence their feature changes will make, any potential legal or licensing issues, etc.
- Cost – the biggest negative for proprietary software is cost – both upfront and ongoing. This is largely due to the fact that development is outside of your control and you have limited influence over timelines, etc. At the end of the day, development houses are commercial businesses who exist to make profit. In the case of in house proprietary software development, by building from scratch your team has to do a lot of heavy lifting that is alleviated when using open source software.
Open source software is visible to a collection of people and organizations who all have vested interest in its creation. Often open source projects are split into components that can be used in many larger systems and are both freely available to anyone to download, use, and attract the code contributions or sponsorship of interested parties. Many internet standards and technologies that underpin the services we use online and in our daily lives are open source software made by a community effort. There are many ways to use open source software without necessarily being completely open.
Free Open Source versus Commercial Open Source
There are two open source methodologies – commercial open source and free open source. Some projects are created purely to solve a common problem and/or accomplish a common goal. These projects are contributed to, free of charge, by multiple developers and the result is kept open source so that everyone can benefit and continue to contribute to.
The clear benefit of Free Open Source is that it’s free. Interestingly, that’s also one of the cons as there is limited support or customization. This is where Commercial Open Source comes in.
Commercial Open Source projects are, in most cases, based on Free Open Source projects, but with dedicated teams that can offer support, customization, and additional sources. These are paid for via subscription models, projects based fees, etc.
Open Source Software Pros
- Lower entry cost – with no licensing to development costs simply using an open source component is free
- Fewer bugs faster fixes – large open source software projects can have many thousands of participants examining the source code, there is a much higher probability that more bugs are exposed compared to the code from a proprietary vendor with a far smaller development team. With more products reliant on the same foundational code there are more ppl with an incentive to quickly address problems.
- Better security – a further benefit of a distributed team is that open source software is more secure overall. Proprietary software vendors depend to some extent on their source code being opaque, it means very few people have access to audit the code and find the flaws that will be exploited by bad actors.
- Free support – often code and tutorials are well documented, more popular projects will have detailed troubleshooting and setup guides. Many projects have wikis and forums where answers can be found to common questions or other users / contributors will answer your questions.
- Able to be customized – with access to well documented source code your dev team can fork and existing project and take it in a totally different direction
- Open standards – many projects support the ethos of open when it comes to standards also, favouring file formats and protocols that can be used freely and encourage interoperability
- No vendor lock in – as you aren’t reliant on a third party, you aren’t stuck with them. There are no terms based agreements and you haven’t handed over the keys to your kingdom.
Open Source Software Cons
- Often less direct support options – you will need to both have contact with domain experts, either on staff or key contributors to the software you are using.
- Usability – the typical front end user experience for open source projects is poorer than commercial projects is often down to budget and the fact that contributors tend to be back end developers rather than front end or UX developers. This is an area you should expect to spend your time and money. (As an aside – UI / UX is very personal to your users and not somewhere you should cut corners.)
- Inhouse skill gap – you are likely to have skills gaps which become apparent as you begin pulling apart open source projects and looking into the source code. These can sometimes be surprises as there is no user guide that details everything up front. My recommendation to mitigate this is to have developers who are “problem solvers” who enjoy delving into the unknown and solving from first principles.
- Risk – any Open Source Software is inherently risky as it can only be as good as your team and their skills. It is essentially a DIY approach which, if you have ever tried your hand at DIY home projects you’ll know, can have unpredictable impacts on budgets and timelines.
Conclusion – Our Approach & Recommendations
In broad terms the two methods we debated as solutions to our software development needs were to either license existing frameworks as toolkits to build things, or to find the technologies we can use to build those tools ourselves. Ultimately we took the path of building our own software by expanding our inhouse development teams and using tried and tested open source technologies as the foundation to build from. Our priorities are to have total control, eek out every ounce of performance, have cutting edge features and to add more features and functionality in the future. Our roadmap is aggressive and extensive, which eliminated most of the existing frameworks for us as they couldn’t confirm whether the capabilities we needed would be possible in future.
Software is a core part of our product and retaining the skills within the business is of critical importance. Perhaps even more imp