The goal is to provide a commercial service to package anything without a lot of back and forth.
Right now, this is just a form that gets piped to our team. It’s very much a beta test, we are just testing this to see if it’s helpful to anyone.
Why do we do this?
My hypothesis is that this will make it easier for companies to adopt Nix. Both in terms of the initial adoption journey, and also to de-risk longer term adoption. Plus it’s fun to try new things.
There are two main buckets where packaging is difficult:
Newcomers that don’t know how to read and write packages yet.
Some packages are just super hardcore to untangle.
Some feedback on the website: For a page that simply displays some text and an input form, this requires an awful lot of JavaScript and content from external services.
I wonder if there are any packages Numtide worked on that could be shown as «if this was requested, we’d price it at X». (But I don’t currently have any hypothetical Nix packages I would like to pay for, so feel free to disregard my idle interest if you believe it won’t help potential customers make a decision).
Let’s see. What I suspect is that some packages will be too large for a single company. But then we can collect all the interested parties and share the costs that way. But first, let’s get more data points.
We might send a pull-request in case the work touches an existing package in nixpkgs.
How would this look like for packaging complex software, like hasura graphql-engine, which is currently marked as “broken” in nixpkgs? What’s the version update like going forward?
By default, package requests get a fresh private repo on https://git.numtide.com/nix-packaging. So here we would duplicate the code and make sure to retain the same MIT license, fix everything and ship it with a new repo. The customer can decide whether to make it open or not.
In cases where the task is to fix existing packages in nixpkgs, we can also send pull requests to nixpkgs. But only if we see that it would be helpful to nixpkgs.
Package upgrades are treated similarly to package requests right now.
This is the current workflow, but it will probably change as we learn.
My impression from this policy is that — in addition to customer choosing the level of openness — there is «a new package won’t have a natural maintainer if Numtide is not interested without payment, and the customer is not capable on their own, and upgrade level of effort is not yet clear enough to discuss recurring services». Presumably, for packages already in Nixpkgs, even if the maintenance story is not good, fixing it is better than not (unless the customer has reasons to hide the interest in the package for now?)…
I actually like this interpretation, if it is true.
Whether to spell it out more (and to say that customers can obviously choose to submit this as «no updates promised for now» to NUR?) is a marketing strategy question, of course.
I want to be careful and not submit new packages to nixpkgs until we have a proper plan to maintain those. And also those packages should make sense to be included in nixpkgs.
But if we can help improve existing recipes then that’s nice.
Around the end of the year I’ll be able to provide some data from Summer of Nix for reference. Likely Numtiders will be faster, as they’re on average a lot more experienced with Nix and some software ecosystems, but not necessarily cheaper.
@zimbatm I really like this offer, and I wish you the best of success with it. I’ve seen many people from commercial contexts express vivid interest in such a service. Capturing that momentum will also benefit the Nix ecosystem, especially as there is no doubt that Numtide will treat the commons respectfully.
@piegames the site is apparently made with Notion, which means it took exactly as much time to make it as needed to write the text. I always wanted to write an API wrapper that renders static HTML from Notion pages, but you have to pick your battles.
Very nice idea! In my professional experience, most of the pain is around Python packaging (something I imagine people at Numtide are very aware of). There the issue is not simply creating one (or even a couple) package (that’s easy enough, but ~nobody I know uses the vanilla Nixpkgs Python infrastructure), but chasing and fixing bugs in the *2nix Python framework du jour. If any of the fixes you create through this service end up being upstream, that would be very nice indeed
Java is usually my biggest enemy, since the *2nix for gradle no longer exists, and the build system itself wants to consume plugins from maven, so you need to hand-write a double IFD to get something close to functional. Also an unholy maven repo → gradle cache translation, for which a snippet is being copied around nixpkgs.
I’ve seen a few packages that gave up and just grab prebuilt binaries.
You’ll be pleased to know that we rewrote the website and it now has 90% less JavaScript than before
Thanks! Assuming that this service works, it would also allow us to improve the language and packaging ecosystem as well. Summer of Nix is great, and I think both projects are quite complementary to each other.
I love this idea. My open source aspirations are important to me. I don’t have a lot of money to throw at getting unstuck re: dependencies, but I do have some.
It would also be very educational. I wouldn’t use this service until I had first tried my hand at packaging the problematic dependency myself. Therefore I’d have enough context to really soak in the decisions made by a pro, since they’re made in a domain that I have context for.
I think this is an awesome idea, and Numtide is the perfect organization to do this well!
My only concern would be that if we promote this widely (which we probably should, depending on how the experiment goes), this would detract from community members outside of Numtide who might also be able to provide packaging services (). This is of course just a selfish concern that you can safely ignore, no hard feelings . I even prefer Numtide taking this up over an ‘open marketplace platform’-style approach, since I trust Numtide to do this ‘right’, while an ‘open marketplace platform’ would be more likely to become a ‘race to the bottom’.
This sounds great in general! Just one thing caught my attention negatively.
Will my package be made available in nixpkgs?
No, this service is complementary to nixpkgs.
In fact, when I started to read your post, I thought “oh I hope the package is going to land in nixpkgs as well”, and was disappointed when I came to that part. What if there is a package (say, cockroachdb) that is really hard to package (without just getting the binary from upstream) and multiple parties request it? You only need to write it once, right? Is the second one requesting it going to get a discount because it’s less work?
While I’m asking this, I wonder how you make sure the package you delivered doesn’t bitrot. Is maintenance part of the deal? Could it be an extra product?
And while I’m asking this, I’m coming full circle. If you would make your package part of nixpkgs, you would (arguably) achieve a higher quality because of many eyeballs and external review, and you can share maintenance with the community. Isn’t that a higher value for your costumers that they might pay for extra?
). This is of course just a selfish concern that you can safely ignore, no hard feelings 
. I even prefer Numtide taking this up over an ‘open marketplace platform’-style approach, since I trust Numtide to do this ‘right’, while an ‘open marketplace platform’ would be more likely to become a ‘race to the bottom’.