What gets in the way of your Raspberry Pi project?

I've been investigating that path too. A proper gateway is cheaper than a converted Pi.

Whether it's MQTT or LoRaWAN gateways you would've had to create driver software or utility software to handle the messaging received and transmitted etc.

What I struggle with is working out which software package works best for these sort of applications. If it's Python then how do you protect your script from being hacked etc.

I would have a similar question for say using Raspberry Pi as say a USB Hub. It's trying to work out what drivers can be installed (and where I get those) and then what additional software layers need to be created to handle the USB data etc. to build an application.

BigG said:

Whether it's MQTT or LoRaWAN gateways you would've had to create driver software or utility software to handle the messaging received and transmitted etc.

It is not often needed to write drivers, except if you are connecting custom designs that aren't supported yet.

BigG said:

What I struggle with is working out which software package works best for these sort of applications. If it's Python then how do you protect your script from being hacked etc.

The security to deal with the execution of Python or other (compiled?) languages is similar. 
It's not something to handle off in a comment. But changing the default user password, running all packages under a dedicated account, and only enabling what's needed is a good start.

Microcontroller software is also vulnerable. Security awareness is needed for any design that needs to be secured.

Most people end up using the few open source projects, or reference code from Semtech. However, as you say, this is just one part of it, and how do you protect from being hacked.

Ordinarily (speaking generally, because I don't know of any orgs using Pi as LoRaWAN gateway) when using Linux in such a way to make a product, there's a process to go through, which results in some hardening of the OS, and eliminating/removing services from starting up if they are not used.
It's a full-time job, at one firm that I worked at, they had a team that was responsible for producing a Linux build that could be used for the org's products. That Linux build would prompt the user to enter the IP address, DHCP, time server, admin password and so on, just as if it were an appliance. The user might not even know it is Linux, since they will never see a shell prompt.

Regarding knowing what drivers etc to use, I can only speak from my experience, where (say) if network communication was needed, then middleware was used to do that, i.e. no creating sockets for instance was needed in the application itself, i.e. the code can be layered. Add in code (can be separate programs) to do upgrades, logging, restarting after a crash, etc., and it's a non unsubstantial amount of work to turn a Linux computer into a product, but feasible for a small team provided some of the effort (like preparing the Linux build and installer) can be offloaded to a team shared for several products.

Wow, you've confirmed my fears. It's complicated.

I guessing here but I think this is where the Yocto project (or equivalent) is supposed to help, where you develop an image file for your application on say a PC and then bundle it with all the Linux OS drivers into one massive custom image to then be uploaded onto the embedded flash or SD card.

I'm trying to support that approach, by giving cross-platform how-to's.
These are a first step, to learn and develop on another platform than the final solution.
Once you've taken that leap of faith (trust me, it isn't a leap in skills - steps are repeatable), the art of adding your design to an OS build suddenly becomes graspable.

But that's not the only path. You can learn to develop for Linux. Or adapt your design to run on Windows and Linux. 

Part of what shabaz describes, I will be doing for an active road test. I will make 2 separate C and C++ applications that will run as a service on a Pi, and that use the network APIs. Feel free to follow along and to comment, ask, critique, rant.

edit: true story!

dougw, to see if this is an asset, it's worth to take a measurement of time spent.
If the device is for an end user, and should be active immediately, this is a yes.
If the device is a development or prototype platform, where you spend the majority in help files, datasheets, compilers, aren't 3 minutes acceptable then?
If time is money: there are SBCs and PCs that start in seconds. It 'll be a cost per minute vs cost per device discussion then.

answer 2  : I think that for an IT guy without previous embedded skills, it's easier to learn and build a meaningful application for a Pi than on a bare metal Arduino.
Let's abstract from A: blinky and B: meshing existing code available on the internet into something that works.

For me it is about how much of my life is spent waiting for computers to boot. Right now I wait for at least 3 computers to boot every day, and sometimes many more than that. It adds up to over a month of my life so far. If you multiply that by the billions of computers and users in the world, you come up to an astronomical amount of time that is wasted every day and every year. A very large segment of computer users leave them running 24/7, at considerable cost, just so they don't have to go though the pain of booting. This can cost about $5 per week in electricity which exceeds the cost of the computer over its life.

Long boot times are not necessary as you point out - they are just accepted as okay because everyone else has been designing this way for a long time.

3 Pis is 9 minutes. 3 minutes if they are convicted to (edit consecutive - ow, I'm not a native English speaker, mistake) concurrent reboots.
Part of time management is to take care that you have something to do while systems are rebooting. Else you have a luxury job.

edit edit:
My job as PM is glimmering trough. If you don't have time for something that can be done at any time, yet tell that you were waiting for something that takes a known amount of time, then there is time left to spend on a moment for self reflection ...