Unfortunately of course Haiku Inc. doesn’t provide even a loose overview of what contracts are considered, what their terms are or suchlike, so the best information we have is what you, yourself wrote about this while working on it, for example:
[quote]
Hi! Work continues on putting Haiku in shape for the R1 release. This week I worked mostly on UI fixes to make our apps look a bit better. [/quote]
The contract was originally about updating WebKit and improving WebPositive, and that stayed the main focus over that year. I did occasionally work on other things as well. There wasn’t any formalized contract or something like that. I could dig out e-mails, but basically they just let me work on whatever I wanted (as usual) until they ran out of funds.
This is actually by design. When the inc was set up, the point was to centralize the donations and have a neutral entity handle them. As a result, the inc tries to not interfere in technical decisions. They can only accept or reject contract proposals set up by developers (not necessarily currently active developers, but of course previous experience with the project helps there).
So yes, I may have done some work which goes “towards R1”. Of course I did. Until now R1 is the only goal we have set, so any progress is progress towards R1. This is the key thing we are discussing here: I think in order to complete R1, we need to define what does NOT fit there, and as a result, define what goes in R2, and possibly beyond.
Also, I think it is worth clarifying the conditions of this contract (and most other contracts where Haiku inc funded developers). I was getting paid about half of what I would be earning with a normal job at the time. And the contractor status in France is quite a mess, with additional paperwork and taxes, almost no healthcare, no paid leave, etc. It also had no visibility since the contract was renewed on a month-by-month basis depending on available funds. (it also involved other problems such as delayed payments, etc). Eventually I learned that there was no money anymore and I had about two weeks to find a new job.
He wrote million characters in his blogposts about his adventures to getting WebKit up-to-date for Haiku. Sometimes he had to make changes in the interface kit or tangential areas to get it better situated for the task what he was about to done. With them his changes makes the whole system better. He described his changes nicely.
You took that sentence where he wrote about it and tells: he was paid to get R1 out of the door?
Maybe it is true in your inertia-system, but i fear there is a flaw somewhere in your logic.
I think this is the source of our differing views. I think the name is very important to attracting users and developers. People are a lot less inclined to try a beta system.
Wow – this discussion has really moved on since yesterday! Much as I am excited about the possible invite, the truth is, I’m currently working on several things at the moment, and am not sure how much time I could give to Haiku. I can definitely say thank you for the offer. It’d be great to be a part of Haiku’s team, and if I joined as an apps/ux-focused guy, these would probably be the first things I’d work on:
I can’t do low-level tasks, so I couldn’t be of help with the kernel, etc. but here are some suggestions. If the Haiku team is serious, and would like me to contribute/commit said ideas, please let me know. Thanks again. 
The color to UI elements already has an open ticket. There are mixed feelings about it. I’m still looking for that perfect shade of blue to use there.
Popping Web+ on first boot does not seem appropriate. The “welcome” icon on the Desktop of the default install should be enough (IIRC it is not in the nightlies, but will be in the releases - betas included). That page also includes a link to the existing user guide.
The hardware compatibility database and script is something everyone keeps talking about. We have all the bits (a script, a database, a web ui) and just need to plug everything together. Help welcome and little discussion needed on this one.
The wording improvements are also easily done, and can be submitted as patches if you have some git skills. Otherwise, just open a ticket with precise suggestions (exact wording). However, “Should I force quit?” would be against our current interface guidelines - we never personify the computer. Also there is already a different “application prevented shutdown” message when an app outright rejects quitting (it happens with NetSurf for example - due to a bug in NetSurf of course).
And finally on the desktop background: the reason we went with the logo is that we wanted to provide a single background and we did not want it to scale it to the desktop resolution. The Haiku logo is something we could easily put in a corner. I’m all for a darker background color (we fake that even in screenshots on the official website!) and some kind of “mixed leaves”, provided that they comply with this (that is, we can use them centered or at a fixed position on screen, and with a single-color background extending to cover the remaining space).
It is not about slavery, it is about desire to serve others with your vision. To make their computing lives better, more secure, more stress-free, etc. If working on Haiku for the benefit of others, more than just yourself, is viewed as slavery…
I think this summarizes why it has taken… what… 17-18 years?.. to get to this point. When every dev does what they WANT to do, towards the goal, then the goal is not really THE goal, it’s just A goal. And, if others are inconvenienced by some mistake they make (ABI breakage), who cares… they weren’t paid for their effort, so let someone else clean up the mess.
When “self” is all that really matters, then the project is nothing more than a general framework with an annotation of: " It’ll be nice when it’s finished." And when that becomes the statement of norm, eventually inertia overcomes momentum and it begins to show… even if it takes over a decade to do so.
Does Linux serve people / organizations / etc? Of course, yes. But why Linux development started and continued? Linus Torvalds doesn’t hesitate to say, he started working on it “Just for fun”, “Because I can” and not to serve others. In the first announcement he wrote “Any suggestions are welcome, but I won’t promise I’ll implement them :-)”. Sounds familiar? And Linux continued to be a hobby until hardware producers started to write Linux drivers for their hardware and software companies started to offer paid support for their Linux distribution. All these are OUTSIDE of responsibility of Linus Torvalds.
Open MIT license (main for Haiku OS components) and read it - https://opensource.org/licenses/MIT! Among other, it plainly states: “THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.”
Yeah, PulkoMandy, you selfish bastard. When will you start serving your fellow Haiku users? Be more like these beacons of the community that have been leading by example for all these countless years…
Proposition for site admins:
can you add ‘not like’ button near ‘like’?
Would PulckoMandy not answer there would be no proper answers from the developers because they are hardly in the forum on the road.
I thank you for the time that you take to answer here in the forum.
And I say it again, this discussion begins to get boring.
Only asking brings nothing (was at the beginning often so on the way), to let act is the key to the goal.
Everyone can contribute something without having to be a developer.
I am looking forward to the BeGeistert and conversations with real people.
I can’t wait for the next WalterCon (in the US) to talk with real BeOS/Haiku people 
i’m very “if it ain’t broke, don’t fix it” type regarding system upgrades – i haven’t jumped at one yet that didn’t break something vital (still got a headache from the filesystem gymnastics of keeping linux and mac systems working together after installing el capitan) so i’d very much like to see R1 still supported for a few years after release, though i do understand and appreciate the difficulty in that. i’m sure i’ll have as much excitement for R2 as anyone, but a system i rely on for work needs to work consistently enough that i can actually deliver to clients.
y’all are doing amazing, btw
It shows people that the project is more “old school”. The current trend is for a point release scheme. RedoxOS has just released 0.3.5, while ReactOS is about to release 0.4.8 - although both also state that they are in alpha phase. It is a good shorthand way of showing the public how far from production ready the OS is - assuming that 1.0 is equivalent to R1.
So, as a matter of interest, what would you give Haiku’s current state as a point release? 0.6, 0.7, 0.8, 0.9? And what will the beta be?
Point release is totally and utterly useless. Does the version “1.2” or “1.8” or “1.12345” give you any indication on how far a project is? nothing-zero does it, because it has no upper boundary.
note: gmail was in beta for over a decade and that did not stop anyone at all from jumping on an invite at the first chance.
VIM is at v8.0.1645 currently. 
looks at Chromium
looks at Firefox
looks at gcc
looks at Ubuntu
looks at Windows
looks at macOS
Mh… I definitely see a trend of NOT using point releases.
Also see all the trouble GTK is going through trying to explain people that no, GTK 4.0 is not GTK4. Point releases may seem nice, but they assume you can ship a stable 1.0, which means all your development releases are 0.something. This sounds fine, until you start thinking about a 2.0 release. If your 2.0 is stable, then all the versions that lead to it would be labelled 1.x. What if you want to ship maintenance versions of 1.0? How do people know if 1.1 is one such maintenance release, or the first step towards 2.0?
So then you turn to Semantic Versioning, which gives clear meaning to each number, but still does not give you a way to release your software as version y.0.0 (a version like this would be “we just made major changes”, which is quite the opposite of a stable version). So once again this is counter intuitive.
So calling the versions alphas and betas makes sense to me. We don’t want to be over-selling, and people who think we are ready for an 1.0 release clearly did not use Haiku seriously enough. We have a crashy web browser, the occasional filesystem corruption, and many other things that are simply not acceptable for a stable release. So beta it is, and beta it will be until we have solved those. Wether people decide to live with these problems is their informed decision.
these things are arbitrary and i don’t have a goat in this race but
major version (binaries compatible on a given architecture), minor version (the part represented by the name), update number; each version spending time in beta (marked ‘b’) before release. each next version is called as beta rather than affecting a prior release’s naming – this way, as support continues for each minor version, there isn’t collision with the next release’s name, which is important since there’s concurrent support for the current release and the two prior releases and development on the next – the kind of weird shit that happens when there’s enough cash for a full-time dev team larger than a football team. the minor releases are stable, followed by bugfix releases and security updates (you can’t know your bugs till the rubber hits the road, and some attack vectors only become apparent when they’re exploited).
freebsd does similar except not with seventeen years since the last major release
if you’ll excuse me, i’m going to sit down and think about what it means that osx is now longer lived than the entirety of classic mac. that has literally never occurred to me.
Can be haiku 18.1 as ubuntu 18 is the year…? 2 version in a year maybe.
