The best commercial case for Open Source is as part of a commoditize-your-complements strategy, in my opinion. Give away the open source part in order to increase demand for your proprietary offerings. Use the open source project to build brand recognition, trust, active community, etc. But earn the money on something complimentary.
Examples:
- Agency / software house, sells consulting, makes open source libraries in their niche.
- Hardware/product vendor, sells devices, open software on the device.
- SaaS vendor for IoT, sells say managed database service, gives away reference software/hardware designs for IoT devices.
This concept is easy in principle, but requires there to be two things which have very strong synergy, and one needs to execute well in both.
There is a decent chance there will be no clear consensus... Maybe people going custom LoRas etc should publish for the 3x most common models. Or maybe the tooling will make it so that switching models in a workflow will be painfree, as has kind of happened with LLMs.
You would have to buy said USB device and get it to your location.
Switching WiFi is only easy if you mean on a single machine/gateway. Swapping the WiFi network equipment in an office is considerably more involved, depending on the desired configuration.
MicroPython is primarily for embedddd devices with on the order of 1 MB of RAM and FLASH. And applications which makes sense with such constraints. If you have hundreds of MB of RAM, better to just use CPython.
They also are rather expensive to maintain, because the leading ledge gets many repeated stresses. And in nordic climates like Sweden there is a snow plow in the winter to remove snow - those occasionally snag on the speed bump - which tends to chip of big chunk, triggering rapid wear.
Companies tend to lie towards their employees in similar ways as to the public. Very often most if the organization ends up believing the lies. The few people that do not tend to keep shut or go elsewhere.
Thanks a lot for your transparency Jeff! Much needed in this area. And your content is quality, much unlike what else being discussed here.
It is really hard to actually make anything substantial on social media exposure. Unfortunately this does not stop many from exaggerating claims in order to (maybe become) be internet famous, or seeing high number of clicks etc. So it is both bad business for creators, and poisoning the discourse for readers - the only real winners are the social media companies and the product companies that get hyped up.
At the very least one must connect to people who would find it valuable (either inbound or outbound), and the value has to be communicated to the prospective buyers. People make their decisions based on how they perceive the product, not based on your view. And the value big enough to overcome friction involved in purchasing, including soft factors like people trusting you with their money. There might be habits and other pieces of inertia that has to be overcome also, and why would they pick your thing over the alternatives. And of course you must be able to charge enough to cover the costs of providing said value.
Businesses are interested in something that can work for them. And the way the LLM based agentic systems are going, it might actually deliver on "Automated Knowledge Workers". Probably not with full autonomy, but in teams lead by a human. The human needs to tend the AKW, much like we do with washing machines and industrial automation machines.
Starting an external CI company for GitHub is becoming more interesting now.
Gitlab offers ability to do CI for external repositories. Travis CI was what everyone used before Github Actions. Time for a new Travis?
At the SMB scale accountants are mostly paid to coach/pester/goade the employees to hand in the necessary paperwork in time. The accountants job is relatively quick from there on.
Anytime algorithms are great for robotics planning, for example. A plan does not have to be perfect to be useful, especially when it can be refined further in the next timestep. And the robot cannot act out the plan instantaneously, so by the time one is close to the point where a non-ideal segment would be, one has had many timesteps to refine/optimize it. But robot could start moving right away.
If we could only complement that battery with a small nuclear reactor, then we'd be in business.
Come to think of it, shipping would be quite interesting for a SpaceX style disruption - there is a market for many many thousands of units - enough to actually get good at building them in a repeatable fashion.
Of course there are considerable engineering and political challenges, to put it mildly.
I saw was because I do not think anyone has used or maintained it since the company behind went belly up. But the code is still out there as open source, probably can be learned from.
Disclaimer: I used to contract for them, but in other areas.
Yeah the USB stick enables the participants to replicate it more easily at home or with friends etc.
Encouraging that the participants are in the driver seat also helps with this.
High performing types in those areas network a lot, and just as much off the clock (or more) as on. From those I know, many of them seem to pick hobbies, friends, holidays, activities, gym, etc that is compatible with connecting with the right people. And that is considered very normal, more ore less expected if aiming for partner type roles.
Yeah that really should have been default. Very big footgun, especially when preserving ordering is default in pandas, numpy, etc. And especially when there is no ingrained index concept in polars, people might very well forget that one needs to have some natural keys and not rely on ordering. One needs to bring more of an SQL mindset.
The pandas workflows have also been stable for the last decade. That there is a new kid on the block (polars) does not make the existing stuff any less stable. And one can just continue writing pandas for the next decade too.
Code using pandas is testable and reusable in much the same way as any other code, make functions that take and return data.
That said, the polars/narwals style API is better than pandas API for sure. More readable and composable, simpler (no index) and a bit less weird overall.