[New to Gemini? Have a look at my Gemini FAQ.]
This article was bi-posted to Gemini and the Web; Gemini version is here:
The previous article provided an introduction of the Advanced!BSD project idea by providing some background as well as discussing the “why”. This article focuses on the “what”.
Shared services or virtualization?
Another general question is what makes more sense to focus on: Some form of virtualization (either full-fledged VMs or paravirtualization like FreeBSD’s jails either with or without VNET) or rather providing shared services? There certainly is a need for both. And while I’m certain that the vast majority of BSD people would be perfectly capable of renting a VM and doing all the things they need themselves, I’m not sure if everybody wants to.
Thinking about what my own use cases would be, the result is likely a mixture of both. If by accident a) the shared service was built upon exactly the software components that I prefer, b) there was a nice interface providing the level of control that I need and c) somebody else kept the whole thing nicely up to date, I wouldn’t say no! If however some service is provided by something that I loathe (let’s say, exim or even sendmail for email!), I’d rather do things myself.
Depending on what preferences people have, the focus of the project might be either way. Personally I’d like to see some high-quality shared services at some point. But that doesn’t necessarily mean the project would have to start with that.
It may look like a logical decision to start with domains. For practical reasons I’d rather stay away from that for the beginning, however. Here’s why: Domain business is hard. The profit margin is very low even for the big players – and you need to have a lot of domains in your portfolio to get decent prices. Before that you’re losing money if you want to compete with the established providers. In addition to that, it’s not exactly simple to properly automate things like domain transfers that can keep real people occupied otherwise. Considerations like this don’t make that field particularly attractive.
DNS is probably a much better field to start with (provided we can get at least one person on board who’s experienced in advanced DNS topics like e.g. DNSSEC and DANE). The initial time to invest into proper configuration of nameservers is not to be neglected but much more on the doable side compared to domain registration and migration for multiple TLDs. And since for DNS you always at least need two servers, this would also be a great one to make use of two different BSD operating systems right from the start!
Plain Web hosting would certainly be the easiest thing to start with. However you definitely want to support TLS certificates with LE today – and supporting wildcard certs for domains requires DNS to be ready for it. Also intermediate hosting is a bit more complex already: A lot of people will want PHP. Some require Python. Others still want Perl. Throw in things like mod_security & friends and the topic gets a lot more complicated pretty quickly. Plus: What webserver to use? Will OpenBSD HTTPd suffice? Should it be Lighty? Nginx perhaps? Or do people need Apache HTTPd?
Email is a huge topic. We’d have to investigate anti-spam and anti-virus software. We’d need to build up reputation for our IPs so that the major mail providers would take email messages from us. And – of course – we should get DNS working first for things like the MX records, SPF, …
Another possibility would be offering complete “products” like a Gitea instance, an XMPP chat server, the Sogo groupware, etc. This only makes sense if we find out that by chance there are a lot of people interested in the same services. In general on the net I’d say WordPress is a sure bet. But my guess is that many people who might be interested in a project like this rather use Hugo, Jekyll and the like.
Each of those topics would of course need to be discussed further if actually a real group forms to make Advance!BSD happen.
Involving neighbors and others?
While I have no doubts that the BSD community is big enough for such a project to succeed with, it might still make sense to connect with some other communities that are also “niche” (i.e. underrepresented due to mainstream exclusivism) but nevertheless important or interesting.
One “neighbor” that comes to mind is the illumos community. While I’d clearly like to focus on BSD, I’d be open to let them participate if they wish. Eventually supporting illumos, too, if people who are capable of providing it join in, would not be a bad thing. We can even offer to give all the revenue that comes from illumos hosting back to that community. It wouldn’t be a loss for us since customers who want that wouldn’t have booked a BSD jail / VM / service in the first place anyway. At the same time it would further diversify the project and help it grow. So there could be a mutual interest.
I’m personally interested in the Gemini project (see FAQ link at the top of this article if you don’t know what it is). As an effort within the so-called “Small Internet” it’s not an incredibly huge community, yet. Due to its nature it’s a pretty technically versed one, though. There’s probably a majority of Linux users there, but taking it into consideration could be for mutual benefit again! Running a gemini server and maintaining a site in Geminispace in addition to the Web that informs about Advance!BSD and the services provided, is really not much hassle. It might well get the project some wider recognition, however. And if we’ve got that Gemini server, anyway, we might consider Gemini hosting as a bonus provided for free to our customers (if they want it). It’s very low on resources and Gemini people would get another free hosting service while we’d benefit from them spreading the word. Win-win.
If there’s enough interest regarding Gemini in the future, we could even decide to dive all in and provide a means of interacting with the services provided by an experimental interface that uses the Gemini protocol! We’d have to explore how to do something like this. Gemini is deliberately a simple protocol, but people have built search engines with it, there’s a wiki system and so on. One nice thing is that client certificates are in common use with Gemini and are often supported by the browser applications. That’s a pretty nice way of proving your identity either without the need for a password of as a second factor.
Just one more example: The POWER platform. It has a much lower market share than amd64 or aarch64 obviously, but there are some people who like it quite a bit. Hosting on ARM is nothing too exciting anymore these days, but hosting on POWER certainly is. We might consider platform diversity as another field that people could select to fund with their money. I can imagine that some people who are not necessarily into *BSD would consider using our services (initially on amd64, of course!) if the money would eventually be used to purchase a POWER 9 server.
Hosting on *BSD running on POWER would certainly be experimental for some time to come, but enthusiasts probably wouldn’t mind that too much. This could be a great chance for the BSD operating systems to improve support on that architecture and it would also be a nice opportunity to diversify the POWER ecosystem. In other words: Another win-win situation (if there’s enough interest in such a thing).
How to get this started?
Well, I’m not going to claim that I now the best way or even have a solid master plan. But here’s some steps that come to mind when I think about it:
Phase 0: Figure out if there’s any interest in something like this at all. Check – there is!
Phase 1: Determine what means of communication would work best for most people interested in the project: A Subreddit? Classic mailing list? IRC / some messenger (which one)? A Web forum? Something else?
Phase 2: Form an early community, collect ideas and thoughts that people have and discuss them! Consider problems that are likely to arise.
Phase 3: Decide on project governance and for example found a core team.
Phase 4: Try to reach some kind of consensus on the concrete goals of the project as well as which are short-term, mid-term and long-term.
Phase 5: Ask people interested about their areas of proficiency, make a list of who can do what. In parallel come up with a list of necessary tasks, then find people who can do the actual work and get things going.
Phase 6+: Let’s not decide on this before phase 2 ends!
There’s two kinds of resources that we need server-related (both hardware and software) and person-related (skills as well as some free time). Regarding servers, any reasonably new machines will probably do. When it comes to the skill sets of people required for the project, things become a bit more complicated. Here’s just a few roles that would need to be filled:
- We obviously need people who install machines, keep them up to date and make sure services continue to run (by setting up proper monitoring and paying attention to notifications) – i.e. administrators.
- Very early on we need web developers: While it is theoretically possible to only interact with customers via email, this is absolutely not a feasible solution. There needs to be some kind of platform where people can login and view / change their services. Also without a somewhat respectable website it will be hard to find any people who’d actually book any service.
- DevOps people. We live in the age of “automate or die!”. Also proper automation does not only mean less manual work but also fewer human mistakes.
- Supporters. We need people who agree to dedicate a bit of time every week to look into problems people have, find a solution to them and interact with the customers via mail.
And so on.
I’d like the project to follow some kind of theme early on. It should convey “yes, we are BSD!” and as long as it’s about a community-driven project, a bit of humor would certainly be appealing to people. We have the daemon and the fork that kind of symbolize BSD as a whole. Which means that we could either use those or try to fit all the specific BSD mascots into the picture. The latter might be harder to do without making it look too artificial and affected. So what about Project: Trident? Just kidding of course! 😉
Here’s one proposal: The mascot could be the polar beast: A daemon riding a wild-looking polar bear in a knightly fashion with a long fork in hand as a lance, a small orange pennant tied to the latter and a halo over its head. Thanks to the bear it’s clear that he’s at the north pole. This theme would allow for a couple of jokes like this: “Pretty cool but not cold(-hearted)” [the south pole has much lower overall temperature] and “Best of all: No clumsy flightless birds here!” 😉
We should make clear though, that at the end of the day we’re all friends in Open Source and despite regularly making fun of each other are not hostile towards Linux but want to go our own way.
Things like that. I’m sure that people come up with all kinds of funny themes if they give it a try.
I’m hoping that this provides some more food for thought and that we’ll be able to establish some kind of communication channel that people interested in this will use to really start discussing things. Regarding my usual articles I’ll probably write about Poudriere next.