I think that’s slightly harsh. Haiku developers must by definition be somewhat different from Linux devs (on average) otherwise they wouldn’t be doing this; they’d be away faffing around with Debian. You don’t code on/in Haiku (I presume) unless you are fond of the BeOS way, even if that’s indirectly via Haiku. I like to tell myself that Haiku developers are a higher quality sub-set of geeks.
3 Likes
Fair point 
The organization in Haiku is very organic. If one developer thinks their time is better spent working on these things, they can work on it. And if people want to submit more proposals there, they can do so as well.
It seems most people are currently at least trying to work on “R1” things (bugfixing, improving hardware support) rather than new features.
There are many motivations to contribute to Haiku. Some people just like to hack on a kernel that’s simpler than the Linux one and/or written in C++ instead of C. You don’t have to care much for the “BeOS way” to do that.
And, it’s great to have a diversity of skills, interests, and motivations 
There is so much work to do anyways, everyone can find a place where they can meaningfully contribute.
4 Likes
Hopefully, devs who like the BeOS way are the largest chunk of devs. If they aren’t, don’t tell me, I don’t want to know.
3 Likes
Glass elevator? You’ve piqued my interest. What’s that? I only joined the Haiku community as of the B4 fanfare. Used BeOS on a machine back in the early 90s at uni.
To chime in a little late to the conversation, I honestly feel that Haiku has hit a sweet spot between maintaining its identity and allowing outside developers from BSD/Linux/MacOS (even windows?) who have the itch to work on a smaller project where their contributions will make meaningful impacts.
I may be a little in the minority in the general population but find uniqueness valuable for uniquenesses’ sake. Many innovations, much critical thought and A good deal of self reflection can be found within uniqueness. And haiku really allows us to take another look at where we are in the OS landscape and give us the opportunity to reconsider paradigms that may have become too inwards looking or set in their ways.
Ps. As a user rather than a contributor, I find myself drawn to Haiku and enjoy booting it up every single time. I put it on a few older machines at my school and for some children it’s their first time to see and use a non-commercial OS. Interface is so simple and easy to use that I rarely even have to explain anything at all before they are typing away or playing games and the fact that it doesn’t really play YouTube very well on these “very mature” devices is actually a massive bonus here.
It does enough to keep the kids entertained and educated, keeps more devices from the landfill and it would be nice to think that I’m opening a few children’s minds by exposing them to alternatives.
Apologies for the rambling wall of text.
7 Likes
Glass Elevator is the title given to post-release1 ideas for the future and is based on a reference to the book (and later, the movie) “Charlie and the Chocolate Factory” where a glass elevator could take you anywhere.
3 Likes
BeOS R5 is and will always be option 3, because it CAN’T be touched. It’s closed source.
Haiku, however, with the initial plan to make an equivalent to BeOS R5, got caught up in the ever increasing demands of modern technology. Newer drive design/interfaces (SATA, PCIe), WiFi, processors, RAM, etc. Unless you freeze development at a specific point in time and simply refine it, you will always be chasing the mirage. But will that ever happen? I don’t know. I believe, had we been able/willing/disciplined enough, we might already have reached R1. But free development gets what free development costs. How many are willing to rally around the absolute goal of getting R1 done, even at the cost of further feature development? Can that even be accomplished?
When Be, Inc. was making the BeBox, they had their own platform. A set-in-stone motherboard design. But those ISA slots and CD-ROM drives posed a problem. When people can add ANY hardware they want into those places, the developers have to go chasing after gremlins constantly. Had they simply said, “THIS is the hardware we provide and we’re not responsible, if you decide to change it.”, things might have gone smoother…
Haiku is trying to be Windows. All things to all people. But it CANNOT be. It will NEVER be able to. The only way we can achieve R1 in any reasonable amount of time (ignoring the 20 years it’s taken so far), is to focus on the hardware we support now and STICK to it! Find motherboards/hardware that are fully supported and STICK to that list. Tell others, “buy these parts, if you want a fully usable hardware experience”. Period.
I have such a system. CPU works. Sound works. Video works. Networking works. I can tell you EXACTLY what that hardware is. We need people to start gathering up motherboard/hardware info from others, that is known/proven to work, and submit that to a page that we point to and tell people, “Go HERE —>”
Once we’ve STOPPED with that list and frozen all feature improvements, and focus solely on refining and perfecting everything to function as reliably as possible on that hardware, I believe we can finally reach R1 within this year or next. But we HAVE to be willing to stop chasing the mirage. We have to be willing to sacrifice our own personal wants (this or that itch we love to scratch; “itches” are not the same as needs; particularly if a devs hardware does not completely function and they can’t afford to buy new, fully compatible hardware ) for the greater good of others. The others who will be users.
However, in that edge case, I think we should set up a fund to help devs get any hardware they do not have, to help them work on getting R1 out the door ASAP. I just paid $150USD to help my Finnish game developer buy a Windows laptop (300 Euro), so he could help me get Stage 3 of my Luposian game closer to completion. So, such a fund is not an unreasonable thing.
1 Like
Be stopped manufacturing and selling BeBoxes pretty early on. In the days of developer releases, in fact. The situation then was similar to how it is now: most people already own a computer (or, today, several computers), and they are not willing to pay several hundred dollars for a new computerjust to run Haiku.
I wouldn’t myself. I spent hours reviewing offers from laptop manufacturers because Iwanted a machine that suits my need: small so I can easily travel with it, powerful enough to do software development, and with a metal frame so I don’t break it by crushing it in my backpack.
Ask another developer, you will get a completely different answer as to what the perfect machine is. But I guessnone of them will say “I plan to continue running it on my desktop from 2001, back when we started this project”. Times move on. If we don’t follow, we fade out into irrelevance.
And the other aspect of this is: R1 is justa version number. On its own, that doesn’t matter to anyone. So,I’m perfectly happy with developers fixing the bugs they hit, and not bothering to fix the bugs thatno one cares about because it affectsjust one application that has since been rewritten, or a piece ofhardware from the 1990s no one owns anymore.
What would be acomplished by reaching R1 in ayear, besides the version number? And also, is that even realistic? There are about 600 bug tickets opened, some of them for decades. So, a year means we would be fixing, on average, two of thesea day? Very far from our current capabilities, and it would be at the expense of everything else (working on applications, fixing bugs on any sort o# modern qardware, writing any new drivers. I don’t think that’s realistic.
Finishing a largeproject like this with a small team of people just working on their freetime takes decades. Not because ofbad planning and wrong goals, but because it’s like trying to dig a tunnel with a teaspoon (or empty the ocean with a spoon or whatever theactual saying is). At that point it doesn’t matter if it’s raining and that refills the ocean. Even if it’s a beautiful sunny day, you’re not going to make a lot of progress.
But we can instead look at how much waterwe already collected, rather than how much there’s left. And appreciate that the project is alive, adapting to the current needs ofthe current users and developers, and keeping up with modern hardware reasonably well. To me this seems like a great success?
6 Likes
How about having smaller but bi-annual beta releases? One of the big problems with the current general beta release cadence (it does exist to some extent) is that Nightly is enabling more hardware than what the current beta supports. While the Haiku developers have previously expressed distaste for a rolling release model, I am not sure if sticking to big (somewhat) annual beta releases is a good idea for the size of the contributors at the moment.
At least with smaller but more frequent beta releases, the processes involved with preparing them still happens (unlike with rolling release) but with reduced deltas from nightlies. Fixes, new features, and hardware enablement can go out faster to people who don’t (and prolly shouldn’t) install nightlies. Additionally, this would lower the instances of apps on HaikuDepot only working on nightlies.
HaikuPorts not having a nightly/beta branch is a problem they should fix.
But to the other points: we already struggle to do beta releases yearly (check when beta4 came out). We could do bi-annual releases but only at the expense of quality and testing
There are lots of things in the nightlies now that I‘d like people to be able to use, even small things like the userguide shortcut respecting translations : )
Honestly we should rather make a proper beta release soon, and I think we are headed in that direction anyway.
1 Like
Annual releases I think would be fine, but the current state is more “oh no, the last release is 1 year old already, we should start thinking about the next one”. This, of course, does not work.
A proper yearly schedule would be much better, and would allow people to plan ahead when to merge huge changes and when to wait because things are in testing and release preparation mode.
4 Likes
There doesn’t necessarily have to be a decrease in testing and quality with more frequent beta releases, if their scope is made smaller than what a yearly beta release typically is right now. Around how long does the testing and preparation for a beta release take? Could it be theoretically reduced if the delta between a beta release and Nightly is smaller, without compromising on quality?
Agreed that this could help to some extent, however it would require the Haiku developers to agree to a schedule and more coordination.
1 Like
In initial post I forgot “home”!:
/boot
/apps
/demos
/develop
/home
/preferences
/system
And with BeOS, Windows and Linux compatibility (or virtualization) layers:
/boot
/apps
/beos
/demos
/develop
/home
/linux
/preferences
/system
/wine