Will the beta release incorporate a formal beta testing cycle over a agreed upon time period?
1 Like
57 developers - with a 9-year release cycle ??? This doesn’t sound healthy.
It seems like Haiku is the development of two different Operating Systems: R1 (BeOS compatible) and R2 (BeOS-like, but modern features). No wonder the project is bogged down.
I think Haiku has become too hung-up on releasing alphas, betas, and Rs. It has become like “writer’s block” or the “putting yips” in golf - the development environment has become so nervy on the subject of releases that it cannot manage to get any out!!!
TAILS Linux has a good development program. It just issues point releases every few months (with a short test period beforehand) - no alphas or betas. I think this shows sensible, disciplined development with mature code.
2 Likes
You forgot the most important part - most of the developers can dedicate only a few hours per week to the project. Out of the 57 contributors mentionned, most submitted just one or two patches. There are much less people who contribute regularly (let’s say once per week or more) - maybe 10 or so.
I think you have a lot of ideas on what the problem are and no action to fix anything. It’s easy to complain, everyone is well aware that the last release was 5 years ago and is embarrassingly old, thanks.
We are working on a release, and the main problem here, let’s state it once again, is that we are gearing up for R1 in terms of infrastructure. This is needed because we have a package manager now, and when we make a release, a lot of people will be installing it and downloading packages. We don’t want our server (remember there is a single server and it hosts everything: git, website, …) DDoS’ed by all these new users. It would make a bad impression. So we need the package repository to be mirrored in various places and the server managed in a sane way. Until recently the server was managed by a single dev who is not a professional sysadmin, and lately he has no time to commit to it anymore. And the new sysadmin team is working hard on migrating to better hardware, cleaning up the setup that accumulated various hacks over the years, etc. This is the critical step before starting the release process.
The other aspect is that we need to split our work between two branches, so that it is possible to provide ongoing support on the R1 branch (with beta1, beta2, etc) all while making major breaking changes in the R2 branch. This also means separate package repositories for each (because they will soon be incompatible), and unfortunately, for this we also need the help of our overloaded sysadmin team (a grand total of 3 persons if I’m not mistaken - also doing that in their free time).
Finally, no one said there would only be a release every 9 years. What I said is:
- Project start to alpha1: 9 years (indeed without releases)
- alpha1 to beta1: 9 years (and 4 releases, alpha1 to alpha4)
- beta1 to R1: let’s aim for 9 years as well, because why not? But during these 9 years let’s try to have 9 to 18 releases (beta1 to beta18), so there is one every 6 month to 1 year.
5 Likes
Life is short, 9 years is to long. I vote for 5 years cycle between releases.
3 Likes
I would have to agree! I wouldn’t mind if R2 took 9 years, but Beta 1 to R1 taking 18 betas and 9 years is clearly not ideal. This actually has me worried. 
2 Likes
Then contribute code so we can advance faster. You know, I’m just extrapolating from the past steps:
If more devs join, and we keep the feature set reasonable, it may happen faster.
10 Likes
Doubtful, with that attitude from the Haiku developers team.
The curve is definitely not linear, but still 
This kind of comment is not helpful and constructive. I am putting a lot of effort in welcoming people and answering their questions to get them started with Haiku. They can then work on whatever they want to, and I actively encourage people to create their own fork when there is a disagreement on something with the existing team (I don’t see this as an agressive thing, forking the code and bringing it in new directions is something healthy for a project).
Can you detail where you think my attitude is wrong? I am willing to improve but I need some more precise feedback.
4 Likes
“beta1 to R1: let’s aim for 9 years as well, because why not?”
I agree with a lot of what you say, but I find statements like this to be very discouraging. And demotivating for developers, like myself, who are interested in getting involved. Is it worth spending the time to learn c++, and the Haiku codebase, if it’s going to be another 9 years before R1? Will anyone still be around in 9 years to use what I wrote?
2 Likes
Is Haiku R1 the goal or is the “goal” completing whatever catches your fancy at the moment?
Are the end-users the most important beneficiaries of your efforts or your own wants/desires?
Do you code to serve yourself or do you code to serve the users of Haiku?
When the devs stop caring about or striving voraciously towards an ultimate end goal, a cause greater than themselves, tasks get less focused and the timeline gets stretched out to absurd lengths… like 9 yr. periods.
I still contend that the cart is before the horse. Even though the majority of the work invested into Haiku has been free, since the very beginning, everyone who was putting their hand to the plow, should have done so, with the desire that every bit of progress was for the benefit of Haiku and it’s users… and, to that end, to do what NEEDED to be done, not just what each dev WANTED to do.
Even if I choose to do something for free, I ask what needs to be done, that I can (am able to) do, not tell people “this is what I want to do”. Proper structure is necessary, even in the absence of finances.
I think the problem, now, is… the main goal (R5 equivilance) was blown past so long ago, and in such a helter-skelter fashion, no one really knows what to do. I think the “goal” is no longer what it once was (except in word), and has become very vague. Hence, the lack of focus on what exactly “beta” represents or when it will be met… to say nothing of R1.
My passion causeth me to write lengthy books… my 'pologies. 
2 Likes
On the contrary, I find it reassuring that the project has a long term roadmap and vision. It means that for the next 9 years, people will be using the code I write. It does not matter if the releases are called “beta” (why are people so put off by this? It’s just a name!), users will download and use them. The final R1 release is when the project enters maintenance mode (with new work going onwards in the R2 branch).
1 Like
Who is going to force devs to do that? Unless there is a compensation of some kind (ie, you pay them), there is simply no way. Why do you think I would work to fulfill your desires, for free? I’m not your slave!
So yes, I contribute to fulfill my own needs first and foremost. However, it is my interest that Haiku does not stay an obscure system and that there is a lively community of users and developers. I can rely on them to provide valuable feedback and ideas, as well as sometimes implementing something so I don’t have to do it myself. This is the only reason which makes me listen to users. And this is not strong enough to compromise my own needs (for example it explains why I’m strongly against giving up on spatial mode in Tracker).
I can’t repeat this often enough: if you don’t have anything to offer in exchange, you cannot drive the devs in any direction. They don’t owe you anything. Gain their respect and they will take your opinion into account. If you can’t contribute code, you can contribute in may other ways, doing UI mockups, translating, taking parts in discussions here with constructive ideas, working on the documentation, etc.
2 Likes
As being a software developer, I can say that one of the main obstacle on the way to contribute to Haiku is not developer’s but user’s attitude. When I imagine that regardless of what I write and how it performs (it will never be perfect) I will receive much more critics than appreciation, keeps me away of publishing what I do and just keeping it for myself.
1 Like
Without offending you, please put yourself in place of software developer. You know very well what NEEDS to be done, but you have no knowledge to do it. You can analyze the problem, learn new skills, try to see how it is implemented in other OSes, but have no clue of what goes wrong. And you can spend 10 years analyzing without approaching to any solution. In this time your users will cry: “You do NOTHING !!!”. On the other hand, you see the piece of code, which is wrong and you see where the problem comes from, even if this is not the top priority for the project. The fix is evident for you, but not evident for others. Will you fix it just because you CAN do it? Now, imagine, when you fix that, your users still cry: “Why you put cart before horse ???” I doubt you enjoy such complains.
You get all my criticism and no appreciation for keeping your code for yourself, however
2 Likes
Haiku Inc. claims to take thousands of dollars every year in donations and other income, it hasn’t specified what happens to that money in many years although like Haiku Beta periodically people say they’re definitely going to get on top of it “soon” and then lose interest entirely. Back in 2014 Haiku Inc used (some of?) the money to pay you specifically to work on getting Haiku R1 out the door.
1 Like
Glad to receive critics from you, they are always constructive
Of course, I will publish my work (applications, not OS) when it is in somewhat good shape. Still the exact meaning of “good shape” depends on comments I read on such treads.
I currently work on porting SBCL (http://sbcl.org/) to Haiku and also to rewrite my own project GeomSpace (https://sourceforge.net/projects/geomspace/) to Haiku. Currently, the SBCL activity is stailed, because Haiku keeps restarting during compilation. There is a bug on this issue. As for GeomSpace, there is no port of FLTK graphic library for Haiku. So, instead of porting the application, I will rewrite its GUI to be native application. This is straight-forward, but takes longer, because every single GUI element needs to be rewritten.
Did they? It’s about time I learn about it then!
They paid me to work on improving the web browser, not to get R1 out.
As for the state of Haiku inc, it’s clearly lacking in financial reports. However, I can tell you that more than half of the budget comes from Google due to our participation in GSoC and GCI. And the other part comes from people deciding to donate to the inc - it is fine if you think they do a bad job and prefer to use your money in other ways. For example, donate to the european HSA (Haiku Support Association) instead, or fund some devs directly (some have Liberapay accounts) or set up bounties on Bountysource. Or just keep it and buy yourself some chocolate instead 
.
On how the money is spent: there is communication when there is a contract for a developer. In the last two years there wasn’t, so the money is just stored for future use for the most part, with the remaining expenses being paying for the domain names, servers hosting Haiku infrastructure, etc. They also refund travel costs to people representing Haiku in various open source conferences (when people request for it - quite often we don’t, since we are ourselves funding the inc by donations it would be just shuffling money around for no purpose).
One major thing the inc funded last year is the coding sprint which I hosted in Toulouse. There the inc paid for the hacking room, bedrooms and food for everyone, as well as funding part of the travel cost for one of our GSoC students so he could addend the event (Google donated some extra amount to GSoC organizations asking us to use it for that purpose). While there was not much communication on it (I did report in the november 2017 activity report, if you want to read about it), this is an essential part of the organization of Haiku, as one of the few opportunities devs have to know each other and also gather in a room to plan for the future of Haiku - in a much more efficient way than when using IRC or mailing lists.
2 Likes