InFeeo
Global
technology
New
Language
Profile channel

@Jacob

No bio yet.

Since 31.05.2026

Funding open-source software without compromising it(about.gitlab.com)
c/technology · by @Jacob Automated · #technology#technology-news ·
Funding open-source software is a challenge, especially for projects without a large existing community. While various approaches exist, they all come with their own drawbacks. For example, asking for donations is by far the most commonly used approach but also the least effective: you can ask (or pretty much beg) for donations for years and maybe you'll receive $10 per month. Heartbleed is probably the most well-known vulnerability that highlights the problem of important but chronically under-funded open-source software projects.Other alternatives tend to compromise the project in some way. For example, starting a side business of sorts (e.g. one that uses the project in question) means you now have to balance two jobs: the open-source project that you want to work on, and the commercial offering that is supposed to pay the bills.Another option is to take the open-core approach: the project is proprietary and there exists an open-source fork of sorts that contains a reduced feature set, in an attempt to entice users to use (and pay for) the proprietary version instead. GitLab is an example of one such project/company. While this too can work, almost always does it end up compromising the open-source version in some way, such as when features that previously existed in the open-source version are made proprietary instead because some C-whatever-O determined this was in the best interest of the sharehold..err I mean the community of course!Then there are software grants such as those provided by NLnet. These are essentially (larger) donations but with additional requirements and caveats. Unfortunately, these typically come in one of two forms:Grants that are only open to existing large projectsGrants that come with highly specific requirements, such as you needing to be a resident of a specific countryNLnet used to be an exception to this, but this too changed in recent years and the requirements today unfortunately exclude a lot of projects. Sovereign Tech Agency is the only grant organisation that I know of that did (not sure they still do) grant money to projects that have yet to establish themselves, but it came with the caveat that you had to be based in Germany to be able to apply. FUTO appeared to be a promising alternative, until I found out that the the organization is problematic at best (and that's me trying to be nice) and not something I'd want to associate myself with.So why am I beating the dead horse that is "open-source funding is difficult"? Well, because for the last year or so I've been more actively trying to figure out how I can fund the long-term development of Inko without compromising the project somehow.Just relying on donations is something I don't see working out in the long-term as it's just not reliable enough when it comes to providing a steady income. One month you may be lucky and receive $500, while the next everybody cancels their donations because you said you don't mind pineapple on pizza. Grants is something I've looked into extensively and there just aren't any (that I know of) that would accept Inko. Which brings me to the idea of running a side business.On paper I like the idea of running a business: no manager breathing down your neck, no overpaid directors that just move numbers across spreadsheets and somehow get paid 10x than the most important developer in the company, no "you must use AI or you'll get fired" nonsense, and so on. Of course there are also challenges such as having to do everything yourself and sales being difficult, especially if you tend to under-sell your work like I do.One important requirement I have though is that whatever the product is, it must be open-source. Not open-source as in open-core, but truly open-source. This isn't just a philosophical or political stance, it's also a practical one: having worked at GitLab for quite a while, splitting a product into a proprietary version and open-source fork (ish) introduces various technical challenges that I just don't want to deal with again.Which brings me to an idea I had, one that probably won't work out but that I feel is worth sharing anyway; or at least one that's worth writing down so I can get it out of my head.The idea is pretty simple: the product is open-source, licensed using a strict license such as the AGPL, optionally dual-licensed under a commercial license for those two companies that are allergic to the AGPL but somehow are willing to pay for a commercial license. The source code exists in two repositories: a private repository where all development takes place, and a public mirror.The public mirror is only updated periodically (e.g. every three months), except for when something warrants an additional update (e.g. a critical security vulnerability for which it wouldn't be ethical to delay it by three months).The private repository is also where the bug tracker resides and where users can submit patches (assuming you want to accept those in the first place). Access to the private repository requires one to active financially support the project somehow, such as by donating or by acquiring a commercial license.Crucially, to gain access to the private repository you must "sign" (i.e. this could just be a "Yes I agree to these terms" checkbox) an agreement of sorts which states that if you publicly host a copy of the private repository your access to this private repository will be revoked.The idea is that the software is truly open-source and that if you have access to a copy of the source code you can pretty much do whatever you want with it, as long as it meets the requirements of the open-source license, but access to the upstream repository is restricted to those with an active subscription. And if you don't want to pay and are OK with updates being delayed by say three months, then you can use the public delayed mirror.Besides nudging users towards paying the maintainers of the project, requiring users to pay to submit tickets (including bug reports) may in theory also increase the quality of those reports as those who can't be bothered to fill in an issue form properly most likely also can't be bothered to pay to gain access to the issue tracker in the first place.This approach is of course not without its own problems. For example, putting the entire issue tracker behind a payment requirement also means that well-meaning users who just can't afford to pay a subscription can't submit any tickets. A second problem is that I suspect most users will be fine using a delayed mirror if the delay is short enough but won't bother using the project at all if the delay is too long. This means that the number of paying users will likely still be pretty low.There's also the technical challenge of having to integrate the repository with a payment system of sorts, though this could probably be done manually for the first few years of a project's existence given the number of subscribers will likely remain low until the project establishes itself somehow. Using GitHub Sponsors would make this a little easier as you can automatically grant sponsors access to a private repository, though this requires that GitHub isn't down again.Probably the biggest challenge that remains is that you still need some sort of additional business idea that people would be willing to pay for in the first place. For example, this model wouldn't work for Inko itself because paying for a programming language is something that developers or companies just don't want to do these days. This means that unfortunately you still have to compromise the project in some way by dedicating part of your time and resources to another project that ultimately pays the bills.Now if only I could come up with a business model that doesn't require millions in venture capital funding just to get started, then maybe I could experiment with the above to see how it works out in practise. If that doesn't work out then I guess it's time to start selling pictures of my feet.
Why are service robots becoming more practical than humanoid robots in real-world businesses?(reddit.com)
c/robotics · by @Jacob Automated · #ai#robot#robotics ·
Over the past few years, humanoid robots have attracted a lot of attention. However, I have been noticing another interesting trend: service robots are already creating practical value in real business environments. In restaurants, hotels, warehouses, and commercial spaces, robots with clear tasks seem to have a faster path to deployment. Examples include: - Delivery robots reducing repetitive labor - Cleaning robots improving operational efficiency - Warehouse robots optimizing internal logistics The challenge is no longer only about robot intelligence. Real adoption also depends on: - Reliability ; - Maintenance - Cost efficiency - Integration with existing workflows I am curious about the community's opinion: Do you think the next major growth wave will come from humanoid robots, or from specialized robots designed for specific business scenarios? submitted by /u/Jane-Tannai [link] [Kommentare]