Interjecting. About 80 people are building & maintaining an operating system, and following their whims to fix the problems that they believe to be most relevant.
What is this email exchange about? Let me lay it out. 1. We are being told what to do. 2. We are being told what is important. 3. We are being told our choices are wrong. There are no diffs, no source code proposals, nothing. There are only wishes. Can you guys please figure it out? Charles <char...@cdaniels.net> wrote: > I'd like to chime in here, on a slightly different subject. > > I think the OP (Clark) raises a point, but I suggest he's coming it > from the wrong angle. I think there's something here to discuss that I > have not seen mentioned in this thread thus far. > > TL;DR: the OpenBSD (and friends) way of thinking is falling further and > further out of fashion with respect to mainstream computing -- I justify > this statement, posit on the need for action, and propose a starting > point. > > Disclaimer 1: I use OpenBSD at various points to refer to the piece of > code, to the development philosophy, to the development team, and to the > community of users. I try to make clear which I am referencing; sorry if > it's confusing. > > Disclaimer 2: I am not an OpenBSD developer. I have contributed only in > very minor ways. I don't speak on behalf of anyone other than myself as > a user of OpenBSD. If it seems at points that I am speaking on behalf of > "OpenBSD" (by any of the previous definitions), I intend that as an > appeal to my perception of what the community of users and developers > feels and thinks, based on my interactions with them here and elsewhere. > If I am wrong in this respect, I invite corrections. > > It certainly seems that there is a great disconnect from the canonical > (small c) definition of "great desktop experience", and the OpenBSD (and > friends) definition. I feel that the broader notion of what a "great > desktop experience" means within the context of the 2019 zeitgeist has > trended towards pandering to the user, in my view to the point of being > patronizing. > > "The users cannot be trusted to manage their own files, it's too hard and > will confuse them." > > "The users cannot be trusted to install their own programs, it's too hard > and will confuse them." > > ... > > "The users cannot be trusted to make decisions, it's too hard and will > confuse them." > > You get the picture (hopefully). > > Part of this is perhaps because the users are "bad at using computers". > I think most anyone who has helped a computer-illiterate family member > or friend with any technology related problem for more than 5 minutes > will see the truth in this statement. But I think it's not the users > fault; many might argue "but if the users would only learn X, Y, an Z > DE/WM/OS/app/etc". I feel that many _do_ argue this, with all the talk > these days of "pushing the envelope", "modern UX", "innovation", and so > on in big blinking neon letters. Ultimately, what this means is telling > the users "yup, you learned $paradigm, but now we have $paradigm++ > because it's the new big thing". If you're a corporate user on a box you > don't control, or you just don't have the experience to do systems > administration on your own, you have to suck it up and deal with it. > > That probably won't be a relateable sentiment to nearly anyone likely to > ever read this document. But as a thought experiment, let's imagine if > vi got a fresh now UX paradigm every year or so, and let's pretend for > the sake of argument that we can't patch it or revert. I think all of us > would not want to use such a program very much. vi takes a while to > learn, and while I (as a diehard vim user) would argue against the > notion of the vi paradigm as the One True Way to edit text, it is > certainly a very powerful tool... because of the time put in to build > muscle memory and intuition about it, knowing that that knowledge will > be applicable to vi implementations for decades to come. Without the > ability to trust that time spent front-loading learning will not be > wasted when $paradigm goes to $paradigm++ in a year, who would ever > invest effort into learning more than the bare minimum? > > Remember that the typical computer user sees their box the way most of > us probably see our cars. It doesn't matter how it works, as long as it > does, but nobody wants a car where the gas and brake pedals switch every > second Tuesday and you wake up one morning to discover the head unit is > now entirely in Sumerian. > > It would seem that this creates a self-perpetuating feedback loop. The > users have a difficult time using the software because they don't learn > it, so the software changes to accommodate the users better, which > further puts folks off of ever learning any of it very well (by > punishing the ones who try). I suggest that this trend has become so > prolific that it has seeped into the general human population's > consciousness around how interacting with computers works. > > Think about it. How many software packages do you know of where a user > could learn how to use it well once and have that knowledge be > applicable for years or decades thereafter? This is something we expect > (as technical folk) of shells and editors, scripting languages, and so > on, but it is not something that the layperson using a GUI can now or at > any point in the past reasonably expect. > > Remember also, that every developer was one a user at some point. It > sure seems that the wall you have to climb over to go from user to > developer keeps getting higher and higher every year. > > There are several problems that I perceive to face us (OpenBSD users > and our friends in similar projects). It ultimately boils down to "we > don't exist in a vacuum", but to be more specific: > > 1. Most people want to use their computers to get work done, and that > often requires inter-operating with software and file formats that are > used by operating systems other than OpenBSD. This generally amounts to > having people to Do The Work to maintain that compatibility, and I think > we're doing alright here. > > 2. More importantly, we need contributors. Developers yes, but also > people to report bugs, people to test new features, people to hang > around on misc@ and help new (and old) users troubleshoot. For a project > to last (and I do wish for OpenBSD to last, and I believe most people on > this list do to), it must have sufficient "new blood" coming in to > sustain (1), and also to push it's loftier technical goals forward. It > seems from the outside looking in that there aren't so many new people > coming into OpenBSD (maybe someone working more closely on development > can comment on this trend or lack threof?), and I would argue that a > large part of this may be because it doesn't conform to people's > expectations of how computers should work "these days". > > Certainly, OpenBSD seems to have little in the way of technical or > philosophical mindshare in the broader computing community, let alone > among laypeople. Perhaps the latter is not so important. Indeed the > former is also not a good goal in of itself, but is a necessary evil up > to a certain point. > > I think the way that much of the Linux (et. al.) world has solved this > (2) is "make it more like what Apple/MS are doing so people think it's > easier". The theory is perhaps that new users are drawn in by the > "friendly" (read: similar to what they are used to) "desktop > experience", and these folks may become community members, then > contributors, and eventually developers. Maybe it works. > Ubuntu/Fedora/GNOME/KDE et. al. certainly have a lot of people working > on them (weather or not the work being done is any good is a discussion > for another thread/flame war). Detractors of those projects might call > it "selling out"... others might just call it "selling". > > I would propose that "just do what everyone else does / what people > expect" isn't the right approach for OpenBSD. Maybe the core team (the > people really Doing The Work, i.e. not me) feels differently, but I feel > that I am echoing sentiments I have observed on this list and in other > OpenBSD related communities: OpenBSD is about technical excellence, only > solving problems can be solved right, and not expending precious > dev-hours on implementing unnecessary (or worse: broken) features. It's > not about working the way some arbitrary group of people think it > should, but rather about working the Right Way, and being Excellent. > > So what should we do? > > I posit that we (the community of OpenBSD) community should be trying > to... perhaps "push" is the wrong word... but "make clear the value of" > the OpenBSD Way (see previous paragraph). Make that way of thinking, and > solving problems more desirable for others to use. I would suggest that > just "make it easy" isn't the right answer, since I think we want to > attract people that can do hard work and have some perseverance, but > those people need to get "hooked" in the first place, and have a general > path forward. I think we're on to something here with respect to how > things are done, in a way that the broader technical community doesn't > appreciate. > > What does that look like? > > I don't think that's as clear. Damn it Jim, I'm a programmer, not a > sociologist. I think a first step is to have some consensus that there > is an issue to be addressed, and at least vaguely what it is. However, I > will propose that this isn't a matter which has a technical solution, > which is unfortunate since the OpenBSD team is clearly very good at > building great technical solutions. I am willing to help to the extent > that my abilities and limited time will permit. > > In closing -- OpenBSD might not have a great desktop experience per se, > but I would argue that it's better than any of the other desktop > experiences that are out there right now. I think we can probably keep > making it better, and that we should. However I don't think shipping a > different WM/DE is going to help. > > RFC. >
