I am giving away my code as FOSS, so I'm doing the following, in this order:
1. Charging for bug reports or feature requests.
2. Support. (And I have great examples of public support as marketing.)
3. Consulting. (This would be exclusively to help companies trying to use my software, but unlike support, it would be about writing the stuff that uses my software and ensuring the client understands it so that I could do a handoff. The result would be carefully commented and documented code, probably just short of literate programming [1].)
4. SaaS. (If I did this, the server might not be FOSS, but the client would be, and it would use encryption.)
And that will only be for companies. For individuals and their personal projects, I'll respond when I have time, for free, for bug reports. (Not feature requests, obviously.) This is to build a clientele of people that might bring my software into their work. And it will reduce bugs.
Sorry to pry, but "will"? Does that mean the business model is yet to be validated? Not pushing back just curious - if it's worked out for you I'd be interested in hearing more, because it sounds like a business model I could adopt for a FOSS project I'm working on.
It depends on what companies have interest in. Below is a list of the ideas I have.
* A build system that is also a package manager like Nix, but usable by mere mortals. Also, it will have an easy way to restrict what builds can do. This one is almost done (well, usable for early adopters, not done); my HN annoucement should be in about three months.
* A VCS that, like Fossil, is self-contained with a bug tracker and everything. It will be able to handle binary assets and HUGE files. It will also be easy-to-use. (I'm going to be testing it on my non-technical wife without telling her how. Once she can use it naturally, I'll probably have a good model.)
I’m definitely interested in the build system / package manager. I have (idly, in a daydreaming sort of way) considered building something like it myself.
I tried to get into Nix recently, but found it difficult to accommodate my workflows within its uncompromising nature. My goal was to set up a reproducible development environment, where anyone at my company could easily get set up to work on our code with a single (or concise set of) action(s). I also tried to use home-manager, which I have heard might have been a mistake.
Anyway, Nix is really only designed to manage the entire world. I wasn’t able to use Nix to build a development environment where other developers and I could work inside of it using our existing tools and workflows, including other package managers that want to mutate things — it seemed that Nix was all-or-nothing. This was too disruptive and a large barrier to adoption for me.
I would love a tool designed for reproducible builds and development environments that can compromise, and do as much as possible immutably while allowing for local mutation on top. That can be a package manager, but also make it easy to use existing package managers too — with the understanding that these other package managers are typically also able to reliably reproduce a build, within their own mutable state. It’s OK if this potentially needs to mutate “the system” in the process to try to reach a goal state (e.g. installing system-wide package managers, xcode, etc.)
Nix really did not seem to be designed to allow me to use other package managers inside it like npm or cargo. It has some support for directly vending packages from those via Nix itself, but that’s not what I want right now; it’s too disruptive to my workflow. We already have all of the build reproduceability that we need via those package managers and via a container based build process. Still, a fair number of development and operational tools are required to develop the software, and I would really have liked a one-click way to set up a development environment that doesn’t require a container (which is not native on Windows or MacOS).
(I admit that it is possible that this idea fundamentally could not work for technical reasons, but it seems plausible that it could.)
Another challenge that I had was with the complexity of the Nix config and file format. It’s basically a programming language, and there isn’t always one right way to do something. That made it considerably more complicated to solve tasks that would be just a single line command if I was using e.g. Homebrew to solve the same goal (brew install xyz).
From a user experience perspective, I would like a tool that provides a simple command line porcelain for mutating the state of the environment, while tracking it immutably under the scenes, so that it’s reproducible. For example, “cmd install foo” should add the “foo” package to my environment (and rebuild it). So at the end I have a declarative description of my environment contents, but I can build that configuration using a sequence of familiar install commands.
I admire what Nix is trying to do, and see a lot of merit to the approach for defining an entire machine’s state immutably. For managing and defining the state of servers, it seems like a great idea. However, the cost to adopt it seems high, and the value would probably be marginal in our case, since we don’t need to manage servers to deploy software (instead deploying only containers); and since existing package managers provide a way to build those containers reproducibly. But containers aren't ideal for defining the tooling used by an interactive local development environment.
Before your comment, my design could not do that. After your comment, I'll make sure it will.
As a build system, it can incorporate other build systems and run them natively. It only makes sense that it should do that for package managers as a package manager. So as long as you understand that most other build systems give you opaque binaries, I can make that happen.
But on the other hand, I think I can make your mutable environment idea work and cross-platform to. My design will require that the environments all be on the same disk because it will use hard links and a SQLite database, but those work on any platform.
But anyway, I also think I could set up mutable environments such that, as long as you only modify it through my tool, it could record those modifications and generate a file to recreate that environment elsewhere. That sounds like Nix, but again, my tool will use other build systems and package managers.
With Fossil I pull in the full issue tracker and forum and have it stored locally, if I'm offline I can then make my changes, comments etc. and when I'm online it all syncs.
1. Charging for bug reports or feature requests.
2. Support. (And I have great examples of public support as marketing.)
3. Consulting. (This would be exclusively to help companies trying to use my software, but unlike support, it would be about writing the stuff that uses my software and ensuring the client understands it so that I could do a handoff. The result would be carefully commented and documented code, probably just short of literate programming [1].)
4. SaaS. (If I did this, the server might not be FOSS, but the client would be, and it would use encryption.)
[1]: https://en.wikipedia.org/wiki/Literate_programming