Hardware engineer here who has spent a good chunk of his career building embedded Linux machines.
I see two options vis a vis near term profitability:
1) charging more, or
2) designing some custom hardware.
I would imagine the first route is the way to go. The second opens your business up to a shedload of risk by directly exposing you to the chip market (here be dragons - now more than ever).
However, at some point, it will likely start to make sense to design your own custom hardware - especially as you add PoE to this. That might be a sensible point to step away from open sourcing the software as well. It's an opportunity to port to a new chipset (Broadcom is a nightmare to work with for anyone who's not at a BigCo), make a clean break with your old codebase, and maybe add some saucy new features.
I would estimate the volume at which this makes economic sense for you on a unit basis is around 10k units. You will likely need to lever up some bucks to cover that production cost, but I conservatively estimate that could trim $10 out of your bill of materials cost.
Two bits from an almost purely hardware engineer's perspective.
Yeah, custom hardware is something I want to do more of, but I have a hard time with it since I'm not much of a hardware guy, so I stick to the Pi. It's a pain in some ways, but it has the big benefit of a large user base so there's a lot of support.
I've been working on the custom PoE HAT for a few months, and the last two months has just been running in circles trying to find ICs in stock. The EE consultants I'm working with say this this would normally be something we could build easily for $20/unit, but with the chip shortage, everything's out of stock. I've even okayed them to look for parts that would drive it up to $50/unit just for the HAT, but we're still not finding anything.
My plan is to do the custom hardware in baby steps, like start with the custom PoE HAT, then see if I can integrate the TC358743 into my HAT for HDMI capture, then maybe move to Pi CM4, then maybe something even more custom.
That seems like a sensible design progression - it lets you slowly chip away at the parts you don't need.
The IC shortage is driving everyone in hardware bonkers at the moment, myself included. I wish I had better input for you here, except that we're in it together for at least the next six to twelve months!
Also an eastern MA EE here - shortages now are the worst I've ever seen (20 years into my career). It's a brutal time to be introducing a new product. I'm having to spin new board revs just to use whatever chips I can currently scrounge from brokers.
Suppliers are telling me they can see the light at the end of the tunnel, but it's looking like mid/late 2022.
A great inspiration to someone dabbling in launching a "lean" hardware business.
How is $15,637.68 in raw materials calculated -- assuming $300 unit price and you sell 100 units? The rPI is $40-80, and the capture card is $35? The case and fan is probably $10 at the most?
My costs are a little higher because everyone's sold out of 2 GB Pis, so I've had to upgrade to the 4 GB, which costs $20 more. The big costs are the Pi boards, the HDMI capture chips, and the case. It also requires a lot of cables and a custom PCB, but I'm trying to reduce those in the next version.
If you're looking for market opportunities try the manufacturing industry. We have loads of CNC machines running very old Windows operating systems. Not only that, we also need support from the manufacturers. Often remote support from overseas.
I currently secure this by unplugging the network when they are done. Exposing a windows 98 machine to the internet is scary. When that machine is a critical production machine it's terrifying. We have 100k in spare parts to keep it running and spare hard drives with images ready to go. So we pay for reliability. Your KVM would mean we don't have to connect these to the internet but still get remote support. For $300 that's a no brainer.
Also, we drill holes in wood, our value add is low. 50% margins would kill us. You may want to look at increasing your cost.
>If you're looking for market opportunities try the manufacturing industry. We have loads of CNC machines running very old Windows operating systems. Not only that, we also need support from the manufacturers. Often remote support from overseas.
Oh, that's a good idea. That wasn't on my radar at all. I live in an area near a lot of manufacturing, so I'll reach out to them. Thanks!
The dilemma around open sourcing versus big (medium?) company taking advantages of such permissive licenses is more and more common these days. Look forward to a good way to resolve this.
I could, but I worry that it would drive down sales volume and reduce total profit. I've sent the product to several IT reviewers, and they all bring up the $300 price point as borderline too high, so I've been reluctant to increase it further.
That said, I've increased prices several times thinking it would drive down volume and it never does, so maybe I should just bump it up again. I just have this weird mental block about exceeding $300.
Anecdata: I found this device interesting when I first saw it announced. I kinda want one. I think I saw it at a $250 price point, and it was already out of my ballpark. If I was buying it for business use, it'd be justifiable at higher.
For personal use, you already priced me out, so who cares? For hobbyists outside of the Silicon Valley-tier of salary, you've already priced most home buyers out, I could spend $300 on TinyPilot, or I could spend $300 on an entirely new server.
> Still, I want to avoid hosting a service where I have to be on-call.
For sure it sucks being on call but usually because you're dealing with someone else's crap. But as the big Kahuna, aren't you in a position to make things reliable enough that on call is not a burden?
To me, needing someone on call is a good sign - means you've got a vital product.
>For sure it sucks being on call but usually because you're dealing with someone else's crap. But as the big Kahuna, aren't you in a position to make things reliable enough that on call is not a burden?
Yeah, I just don't even want to think about it. I want to be able to disconnect on the weekends safe in knowing that there's nothing I'm missing that's causing a big outage for a bunch of my customers.
You're selling an enterprise product. The service component of it is going to be key to revenue growth. You should probably be working to get to the point where you can hire professional sysadmins to think about it so that you can disconnect on the weekends.
Either that or get over the "I don't work weekends" thing and recognize that if bootstrapping an enterprise vendor were easy, then everyone would do it.
As someone who has run two services for over a decade, even though it's only down to maybe 2-3 nights a year where there's an off-hours outage, it's annoying enough to make me question keeping the things running. It always seems to happen with the worst possible timing!
> Instead of buying the hardware from me, they simply built their own devices. And because the software has a permissive open-source license, they were free to use it in their company without paying me anything.
> This is an extremely common problem in open-source. An open license helps people discover your product and encourages them to use it, but it also allows big corporations to profit from your work while offering nothing in return.
in the same way you do not contribute back to https://pikvm.org but you make profit from it
> It is my code… sort of. The freelancers who work on TinyPilot sign a contract saying that I own the intellectual property of code they contribute, but I also have accepted a handful of contributions from volunteer developers. My understanding is that developers who contributed free code technically co-own the copyright to TinyPilot’s code with me.
> I released TinyPilot under the MIT license because it gives me flexibility as well. I think I can “fork” the code myself into a different license and just say that it also uses MIT-licensed code, but I’m not totally sure how that works.
again, not true. Your code is based on someone else code, https://pikvm.org and you are making profit from it without contributing.
I don't know the specifics of how TinyPilot is supposedly based on Pi-KVM, but seeing how the all Pi-KVM repositories seem to be licensed under GPL 3.0[^1] even distributing his code under MIT seems potentially legally problematic. See the "same license" clause of the GPL 3.0 for derivative projects and projects even just using GPL 3.0 code.
This is of course only relevant if the above comment is correct and TinyPilot actually derives from and/or uses code from GPL 3.0 licensed parts of the Pi-KVM project. I do not know if this is the case.
>Your code is based on someone else code, https://pikvm.org and you are making profit from it without contributing.
TinyPilot is not based on PiKVM.
I started the project before I was aware of PiKVM, and the PiKVM author invited me to check out his project.[0] That led me to uStreamer, the video streaming tool that PiKVM published. I use uStreamer under the GPL and keep all the code in a separate repo. That's the only component that TinyPilot and PiKVM share.
>in the same way you do not contribute back to https://pikvm.org but you make profit from it
I do contribute to uStreamer. I actively maintain the Ansible role[1], and I've also contributed financially.[2] I'm in regularly contact with Maxim about how we can work together.
If Maxim is unhappy with our arrangement, I'm happy to hear from him. PiKVM seems to have an odd contingent of fans who have taken it upon themselves to pop up whenever people are discussing TinyPilot to claim that I'm exploiting Maxim.
2. > PiKVM seems to have an odd contingent of fans who have taken it upon themselves to pop up whenever people are discussing TinyPilot to claim that I'm exploiting Maxim.
no, people speak-up when they see injustice, thank you for the free insult.
I'm doing something like that now, except the premium features are just in a Pro version.[0] There are only a handful of purchases per month of the Pro version, and I've wondered whether I should scrap it for some other model. It's possible that even though people don't buy the software standalone, it's part of what makes people purchase hardware kits from me, as the hardware packages all include the Pro license.
Another classic way to monetize open source is via support contracts. Enterprise love support contracts where someone has to answer the phone. This doesn’t help the “no on call” criterion, but is a good way to increase revenue.
Or sponsorships… this project is sponsored by X. But that’s probably not a good fit for a hardware/software combination.
For your book; You wrote about how to address high level goals (write an interesting blog) which depend on low level details like verb agreement.
My answer to you is : hyperlinks.
In your high level chapter, mention various skills like verb agreement followed by a icon for "detailed glossary" skill that links to your low level details about how to do verb agreement. Then if someone doesn't know how to do it, they can click the link.
To give a more concrete example, one of the things I want to talk about is "hooks." The first few sentences of any piece of writing should convince the reader that the rest of the piece is worth their time. That applies to blog posts, design documents, emails, tutorials, etc.
I understand what you're saying about how I could bury a foundational topic in a glossary, but "hooks" are a topic that I think 80% of my readers don't understand, so it feels weird to bury it later in the book rather than introduce it early and then talk about higher level things that depend on it.
Use pi-kvm please. As far as I can tell there is a pretty one-way relationship between the two.
The market for this tool is probably large enough for 2 or even more different suppliers that have differentiated themselves to serve different people with different priorities. These two proje ts are slightly different, where TinyPilot seems to be aiming for a less diy user experience, so on that level, it's fine for TinyPilot to exist. That is a perfectly ok differentiator, and it's perfectly ok to make that a product vs a project, ie charge money for it and make it your livlihood.
But, me being aware of both projects, something about the way TinyPilot presents itself just leaves a bad taste in my mouth. I think he should be acknowledging pikvm more, or, at all, and it would give a much better impression if I ever saw him on the pikvm discord or submitting pr's to the pikvm github. And as someone else already mentioned, it's at least a question to be answered whether it's even allowed let alone nice, to take GPL3 code and create a MIT derivative of it.
The more he says "It's my code" without even any qualifiers, the less sympathy I have, and I want people to be able to make an honest living while working with open source hardware and software.
It's possible I'm being hugely unfair, right? I'm totally aware of that. So what I am saying is, having been aware of both projects for some time, this is the impression I'm left with, and it's not because the pikvm developer ever wrote a blog post complaining about it or anything like that. He's just plugging away at his project like a machine. If the TinyPilot developer wants me not to have this impression, anf believes it is undeserved, then let this be a heads up that this is the impression he is creating. Go ahead and enlighten me, and along the way, everyone else.
I have spent thousands of employers and customers money and at least few thousand of my own on similar products in this category over the years, and even a year ago before the new hardware pi hat was ready, pikvm wiped the floor with my shiny new Lantronix Spider, and I donated the cost of a new Spider to pikvm, and since then have not regretted it at all. The guy is a machine and not a complainer or blogger.
PiKVM is a great project, but I'm not sure why its fans feel the need to dump on mine.
As I mentioned in another comment,[0] TinyPilot is all original code - it's not a fork of PiKVM.
TinyPilot depends on uStreamer, which is a PiKVM tool. I use it under the terms of the license and have contributed back in several ways.
>I think he should be acknowledging pikvm more, or, at all
I publicly credit uStreamer in several places in the TinyPilot repo and on the website. What kind of acknowledgement are you expecting?
>The more he says "It's my code" without even any qualifiers, the less sympathy I have, and I want people to be able to make an honest living while working with open source hardware and software.
Why does using an external open source component make TinyPilot not my code? TinyPilot also depends on Flask and nginx and Linux. Is any project that has an open source dependency somehow stealing?
PiKVM depends on many open source projects as well. What's the difference?
^^ this, I am glad someone else opinion is similar to what I wrote in previous comment.
Mine was downvoted and flagged, it seems tinypilot(mtlynch) has "an odd contingent of fans who have taken it upon themselves" but to downvote when someone mentions pikvm
This is a tough problem. Open source is a business tool, and for some also a raison d'être. If open source is not a raison d'être for you, then consider changing how much of the product is open source.
I read the blog post and it seems like you feel like you have to sell this product yourself. But you don't have to do all that, hire a salesman? Pay them commission. That's what they do. They enjoy the challenge.
Also maybe hire a manager? It's a job that many people are good at. They will run the warehouse and report back to you. If your most valuable contribution is technical guidance and software improvements, then label yourself the CTO and hire experts in these other areas.
From the pie chart 40-50% of the total expenses look fixed, so selling more units would obviously increase profits quickly. As would selling power and HDMI cables and other sundries that have a good markup but give buyers convenience.
50% profit margin on the hardware is reasonable - but it means you can't really sell wholesale (although an EU reseller that can take care of delivery, import and VAT may get you more customers there).
Obviously it's very hard to raise prices for the existing product (unless it was a version 2) - Can the device be redesigned to reduce cost? - i.e. a custom single board capture and CPU etc. but that would involve development costs
I haven't been in enterprise IT for a while, but the enterprise features that you could have closed-source that would encourage big corps to buy (and pay a premium) which hobbyist buyers couldn't care less about:
- SNMP support (it's on the network, it should report what it is)
- Raise SNMP trap (or other alert into $proprietary_monitoring system) when the screen looks like a BIOS screen
- timestamped video storage of any activity that happened (auditors will love this)
- integrated authentication with LDAP / ActiveDirectory so that you can set up a group which has access to all TinyPilots
* Admin-controlled certs and mutual TLS for the webface.
* send a webhook for each snapshot, maybe sign and ship the image somewhere durable
You could likely work out a recurring charge per unit for these features. I.e. enterprise buys the units at normal price and then pays $100/unit/year for enterprise features. Remember that you're competing here against the hardware vendor's on-board management. That's not usually free or as flexible as you can be.
Also I want to emphasize something that the parent poster said. Medium and large companies have to fulfill legal and certification obligations (SOX, SOC1/2) that require them to defend against audit challenges. If you can tie into that story and satisfy their compliance controls with just a little configuration these companies will buy.
This is disheartening, so much work for something that doesn’t even pay better than a typical software engineering gig, and I don’t really see potential for huge growth either. Why do people even bother? Is it just a desire to have a hobby that also maybe makes some money?
You seem to be far enough ahead of other commercial offerings to slow down the new feature pace. I'd consider going from 3 contract developers down to one so that the project can have better margins. Then, when growth allows, ramp it back up.
The 3d printed case also seems like an opportunity. I imagine that's costly both from a materials and labor perspective. There would be a large one time cost to convert that to a molded case, but the per-unit cost would drop a lot. If the design is stable now, I'd consider that.
>You seem to be far enough ahead of other commercial offerings to slow down the new feature pace. I'd consider going from 3 contract developers down to one so that the project can have better margins. Then, when growth allows, ramp it back up.
Yeah, the focus now is for features that attract enterprise clients or building a SaaS complement. Also, to clarify, it's three part-time developers, so it's about 30-50 hours per week of total dev work across the three of them.
>The 3d printed case also seems like an opportunity. I imagine that's costly both from a materials and labor perspective. There would be a large one time cost to convert that to a molded case, but the per-unit cost would drop a lot. If the design is stable now, I'd consider that.
I looked into that a few months ago[0], and the up-front cost would be $20-40k, and it wouldn't drop the unit price by much. I have an unfair advantage by living in MA, where the state subsidizes 75% of 3D printing costs for businesses registered in the state.[1] I'm sticking with 3D printing for now because the design has changed slightly every few months, and I like the flexibility it offers.
It might be a cliche but there's a reason people say "Turnover is vanity, profit is sanity". If you're turning over 30k without profit you're basically running a charity not a business.
54 comments
[ 4.2 ms ] story [ 110 ms ] threadI'm happy to take any feedback or answer any questions about this post.
I see two options vis a vis near term profitability: 1) charging more, or 2) designing some custom hardware.
I would imagine the first route is the way to go. The second opens your business up to a shedload of risk by directly exposing you to the chip market (here be dragons - now more than ever).
However, at some point, it will likely start to make sense to design your own custom hardware - especially as you add PoE to this. That might be a sensible point to step away from open sourcing the software as well. It's an opportunity to port to a new chipset (Broadcom is a nightmare to work with for anyone who's not at a BigCo), make a clean break with your old codebase, and maybe add some saucy new features.
I would estimate the volume at which this makes economic sense for you on a unit basis is around 10k units. You will likely need to lever up some bucks to cover that production cost, but I conservatively estimate that could trim $10 out of your bill of materials cost.
Two bits from an almost purely hardware engineer's perspective.
(With <3 from Eastern Massachusetts.)
Yeah, custom hardware is something I want to do more of, but I have a hard time with it since I'm not much of a hardware guy, so I stick to the Pi. It's a pain in some ways, but it has the big benefit of a large user base so there's a lot of support.
I've been working on the custom PoE HAT for a few months, and the last two months has just been running in circles trying to find ICs in stock. The EE consultants I'm working with say this this would normally be something we could build easily for $20/unit, but with the chip shortage, everything's out of stock. I've even okayed them to look for parts that would drive it up to $50/unit just for the HAT, but we're still not finding anything.
My plan is to do the custom hardware in baby steps, like start with the custom PoE HAT, then see if I can integrate the TC358743 into my HAT for HDMI capture, then maybe move to Pi CM4, then maybe something even more custom.
The IC shortage is driving everyone in hardware bonkers at the moment, myself included. I wish I had better input for you here, except that we're in it together for at least the next six to twelve months!
Suppliers are telling me they can see the light at the end of the tunnel, but it's looking like mid/late 2022.
Hardware that just works is worth more. Charge $100 more for unit 1 orders, then discount down to the current price in quantity.
How is $15,637.68 in raw materials calculated -- assuming $300 unit price and you sell 100 units? The rPI is $40-80, and the capture card is $35? The case and fan is probably $10 at the most?
https://mtlynch.io/retrospectives/2020/12/#voyager-pricing
My costs are a little higher because everyone's sold out of 2 GB Pis, so I've had to upgrade to the 4 GB, which costs $20 more. The big costs are the Pi boards, the HDMI capture chips, and the case. It also requires a lot of cables and a custom PCB, but I'm trying to reduce those in the next version.
I currently secure this by unplugging the network when they are done. Exposing a windows 98 machine to the internet is scary. When that machine is a critical production machine it's terrifying. We have 100k in spare parts to keep it running and spare hard drives with images ready to go. So we pay for reliability. Your KVM would mean we don't have to connect these to the internet but still get remote support. For $300 that's a no brainer.
Also, we drill holes in wood, our value add is low. 50% margins would kill us. You may want to look at increasing your cost.
Oh, that's a good idea. That wasn't on my radar at all. I live in an area near a lot of manufacturing, so I'll reach out to them. Thanks!
The dilemma around open sourcing versus big (medium?) company taking advantages of such permissive licenses is more and more common these days. Look forward to a good way to resolve this.
That said, I've increased prices several times thinking it would drive down volume and it never does, so maybe I should just bump it up again. I just have this weird mental block about exceeding $300.
For personal use, you already priced me out, so who cares? For hobbyists outside of the Silicon Valley-tier of salary, you've already priced most home buyers out, I could spend $300 on TinyPilot, or I could spend $300 on an entirely new server.
For sure it sucks being on call but usually because you're dealing with someone else's crap. But as the big Kahuna, aren't you in a position to make things reliable enough that on call is not a burden?
To me, needing someone on call is a good sign - means you've got a vital product.
>For sure it sucks being on call but usually because you're dealing with someone else's crap. But as the big Kahuna, aren't you in a position to make things reliable enough that on call is not a burden?
Yeah, I just don't even want to think about it. I want to be able to disconnect on the weekends safe in knowing that there's nothing I'm missing that's causing a big outage for a bunch of my customers.
Either that or get over the "I don't work weekends" thing and recognize that if bootstrapping an enterprise vendor were easy, then everyone would do it.
> This is an extremely common problem in open-source. An open license helps people discover your product and encourages them to use it, but it also allows big corporations to profit from your work while offering nothing in return.
in the same way you do not contribute back to https://pikvm.org but you make profit from it
> It is my code… sort of. The freelancers who work on TinyPilot sign a contract saying that I own the intellectual property of code they contribute, but I also have accepted a handful of contributions from volunteer developers. My understanding is that developers who contributed free code technically co-own the copyright to TinyPilot’s code with me.
> I released TinyPilot under the MIT license because it gives me flexibility as well. I think I can “fork” the code myself into a different license and just say that it also uses MIT-licensed code, but I’m not totally sure how that works.
again, not true. Your code is based on someone else code, https://pikvm.org and you are making profit from it without contributing.
This is of course only relevant if the above comment is correct and TinyPilot actually derives from and/or uses code from GPL 3.0 licensed parts of the Pi-KVM project. I do not know if this is the case.
[1]: https://github.com/pikvm/pikvm/blob/master/LICENSE
TinyPilot is not based on PiKVM.
I started the project before I was aware of PiKVM, and the PiKVM author invited me to check out his project.[0] That led me to uStreamer, the video streaming tool that PiKVM published. I use uStreamer under the GPL and keep all the code in a separate repo. That's the only component that TinyPilot and PiKVM share.
>in the same way you do not contribute back to https://pikvm.org but you make profit from it
I do contribute to uStreamer. I actively maintain the Ansible role[1], and I've also contributed financially.[2] I'm in regularly contact with Maxim about how we can work together.
If Maxim is unhappy with our arrangement, I'm happy to hear from him. PiKVM seems to have an odd contingent of fans who have taken it upon themselves to pop up whenever people are discussing TinyPilot to claim that I'm exploiting Maxim.
[0] https://mtlynch.io/tinypilot/#borrowing-from-a-similar-proje...
[1] https://github.com/tiny-pilot/ansible-role-ustreamer
[2] https://github.com/pikvm/pikvm/commit/2eda123bba2b2d531b30f5...
2. > PiKVM seems to have an odd contingent of fans who have taken it upon themselves to pop up whenever people are discussing TinyPilot to claim that I'm exploiting Maxim.
no, people speak-up when they see injustice, thank you for the free insult.
I'm doing something like that now, except the premium features are just in a Pro version.[0] There are only a handful of purchases per month of the Pro version, and I've wondered whether I should scrap it for some other model. It's possible that even though people don't buy the software standalone, it's part of what makes people purchase hardware kits from me, as the hardware packages all include the Pro license.
[0] https://tinypilotkvm.com/product/tinypilot-pro
Or sponsorships… this project is sponsored by X. But that’s probably not a good fit for a hardware/software combination.
To give a more concrete example, one of the things I want to talk about is "hooks." The first few sentences of any piece of writing should convince the reader that the rest of the piece is worth their time. That applies to blog posts, design documents, emails, tutorials, etc.
I understand what you're saying about how I could bury a foundational topic in a glossary, but "hooks" are a topic that I think 80% of my readers don't understand, so it feels weird to bury it later in the book rather than introduce it early and then talk about higher level things that depend on it.
The market for this tool is probably large enough for 2 or even more different suppliers that have differentiated themselves to serve different people with different priorities. These two proje ts are slightly different, where TinyPilot seems to be aiming for a less diy user experience, so on that level, it's fine for TinyPilot to exist. That is a perfectly ok differentiator, and it's perfectly ok to make that a product vs a project, ie charge money for it and make it your livlihood.
But, me being aware of both projects, something about the way TinyPilot presents itself just leaves a bad taste in my mouth. I think he should be acknowledging pikvm more, or, at all, and it would give a much better impression if I ever saw him on the pikvm discord or submitting pr's to the pikvm github. And as someone else already mentioned, it's at least a question to be answered whether it's even allowed let alone nice, to take GPL3 code and create a MIT derivative of it.
The more he says "It's my code" without even any qualifiers, the less sympathy I have, and I want people to be able to make an honest living while working with open source hardware and software.
It's possible I'm being hugely unfair, right? I'm totally aware of that. So what I am saying is, having been aware of both projects for some time, this is the impression I'm left with, and it's not because the pikvm developer ever wrote a blog post complaining about it or anything like that. He's just plugging away at his project like a machine. If the TinyPilot developer wants me not to have this impression, anf believes it is undeserved, then let this be a heads up that this is the impression he is creating. Go ahead and enlighten me, and along the way, everyone else.
I have spent thousands of employers and customers money and at least few thousand of my own on similar products in this category over the years, and even a year ago before the new hardware pi hat was ready, pikvm wiped the floor with my shiny new Lantronix Spider, and I donated the cost of a new Spider to pikvm, and since then have not regretted it at all. The guy is a machine and not a complainer or blogger.
I tried both solutions a couple months ago with one of these cheap USB HDMI capture dongles https://www.amazon.ca/MavisLink-Capture-Definition-Acquisiti...
& pi-kvm had better performance
As I mentioned in another comment,[0] TinyPilot is all original code - it's not a fork of PiKVM.
TinyPilot depends on uStreamer, which is a PiKVM tool. I use it under the terms of the license and have contributed back in several ways.
>I think he should be acknowledging pikvm more, or, at all
I publicly credit uStreamer in several places in the TinyPilot repo and on the website. What kind of acknowledgement are you expecting?
>The more he says "It's my code" without even any qualifiers, the less sympathy I have, and I want people to be able to make an honest living while working with open source hardware and software.
Why does using an external open source component make TinyPilot not my code? TinyPilot also depends on Flask and nginx and Linux. Is any project that has an open source dependency somehow stealing?
PiKVM depends on many open source projects as well. What's the difference?
[0] https://news.ycombinator.com/item?id=27388827
Mine was downvoted and flagged, it seems tinypilot(mtlynch) has "an odd contingent of fans who have taken it upon themselves" but to downvote when someone mentions pikvm
Also maybe hire a manager? It's a job that many people are good at. They will run the warehouse and report back to you. If your most valuable contribution is technical guidance and software improvements, then label yourself the CTO and hire experts in these other areas.
That would first mean to get an investor so you can hire. Which is a completely different story.
50% profit margin on the hardware is reasonable - but it means you can't really sell wholesale (although an EU reseller that can take care of delivery, import and VAT may get you more customers there).
Obviously it's very hard to raise prices for the existing product (unless it was a version 2) - Can the device be redesigned to reduce cost? - i.e. a custom single board capture and CPU etc. but that would involve development costs
- SNMP support (it's on the network, it should report what it is) - Raise SNMP trap (or other alert into $proprietary_monitoring system) when the screen looks like a BIOS screen - timestamped video storage of any activity that happened (auditors will love this) - integrated authentication with LDAP / ActiveDirectory so that you can set up a group which has access to all TinyPilots
* Admin-controlled certs and mutual TLS for the webface.
* send a webhook for each snapshot, maybe sign and ship the image somewhere durable
You could likely work out a recurring charge per unit for these features. I.e. enterprise buys the units at normal price and then pays $100/unit/year for enterprise features. Remember that you're competing here against the hardware vendor's on-board management. That's not usually free or as flexible as you can be.
Also I want to emphasize something that the parent poster said. Medium and large companies have to fulfill legal and certification obligations (SOX, SOC1/2) that require them to defend against audit challenges. If you can tie into that story and satisfy their compliance controls with just a little configuration these companies will buy.
The 3d printed case also seems like an opportunity. I imagine that's costly both from a materials and labor perspective. There would be a large one time cost to convert that to a molded case, but the per-unit cost would drop a lot. If the design is stable now, I'd consider that.
>You seem to be far enough ahead of other commercial offerings to slow down the new feature pace. I'd consider going from 3 contract developers down to one so that the project can have better margins. Then, when growth allows, ramp it back up.
Yeah, the focus now is for features that attract enterprise clients or building a SaaS complement. Also, to clarify, it's three part-time developers, so it's about 30-50 hours per week of total dev work across the three of them.
>The 3d printed case also seems like an opportunity. I imagine that's costly both from a materials and labor perspective. There would be a large one time cost to convert that to a molded case, but the per-unit cost would drop a lot. If the design is stable now, I'd consider that.
I looked into that a few months ago[0], and the up-front cost would be $20-40k, and it wouldn't drop the unit price by much. I have an unfair advantage by living in MA, where the state subsidizes 75% of 3D printing costs for businesses registered in the state.[1] I'm sticking with 3D printing for now because the design has changed slightly every few months, and I like the flexibility it offers.
[0] https://mtlynch.io/retrospectives/2021/02/#scaling-manufactu...
[1] https://www.mass.gov/doc/946-cmr-800-innovation-voucher-prog...
Ah, wow, yeah, that would be hard to beat.
I never empathized with a line in a blog more.