Haiku itself rarely changes for the sake of it, we only fix things here and there. Breaking changes mostly happen at HaikuPorts nowdays, actually since the buildbots are active…
I thought it was already decide and voted. If not what we are waiting for? I think this is the only reasonable solution to both provide a stable release and begin advancing the system.
My impression instead is that some people here fear that R1 would be basically abandoned since it’s so much time…but the fact is that we have to do a release or the project is going to certain death.
The fact that some people are keeping the project in hold because of their likes isn’t a justification for holding the release more.
Having a static libshared may be a good compromise. My thoughts are:
- We don’t have more time to wait for more APIs to become public, everyone had enough time to do so.
- Private APIs aren’t provided with the warranty they become stable.
- I didn’t decide this model of development, advancement in the Haiku API were usually opposed by some devs, now we can just live with the consequences.
In any case, if needed I don’t see why we can’t have an R1.5 release where compatibility with BeOS is kept but also more advancements in the system are included.
For now, my idea is that we need to do a release with what we have.
1 Like
To be honest there were so much different plans for R1 and different approaches tried that I don’t even remember what is agreed upon or not. If no one else has an alternative plan, let’s use this one for now.
I offered to be the maintainer for the R1 branch, with the condition that a proper tool for managing that would be setup. Now that Gerrit is up and running, I will assume the responsibility - help from others is welcome, of course, but back in the discussion I mentioned other people present were mostly interested in moving onto new things for R2.
I don’t, however, feel the pressure to do a release. I think it is way overrated. I know it will attract a lot of attention and I wouldn’t want to ship something with embarrassing bugs.
The main reason for not having a release yet is not there, however: we still need the last mile in terms of system administration, namely setting up a separate package repo for it. This probably also means figuring out a scheme for managing haikuports. I think korli’s trimestrial branches should be used here (the idea is that every 3 month he makes a new branch based on the trunk, and then for 3 months, backport only important fixes from the trunk while trying to not update too many recipes - this should provide something more stable than using the trunk of haikuports directly)
On libshared: there already is a libshared.a, and the BPrivate namespace. Both should be used when introducing new private APIs, and there is no problem doing that. This way, when we make changes, old software linked against an old version of the lib continues to run. I think we have more than enough features for R1 already, so no need to wait more on getting things out of that lib for now. We can do that later.
As for advancement in the API, my view is “not yet”. The goal here is to force people to finally branch out the R1 branch (without introducing new unstable things in it continuously). Once the R1 branch is created, the R2 branch can be used as a playground for experimenting with new things, and when they reach some maturity and stability, they can be integrated in master and unleashed on unsuspecting users. There is no problem adding things in that way. What I have a problem with is things getting directly in our current trunk branch which is what we also tell users to download and use. Note that with Gerrit, it’s possible to have such changes stored in Gerrit and easily grabbed from there by developpers (just a git cherry-pick away). So this may be another way to deal with such “exploratory” changes.
Why not some release each year? With some natural cycle.
Naming and releasing natural cycle:
Haiku 18 V (vernal equinox) — the birth of a new system, old still receive bug fixes.
Haiku 18 S (summer solstice) — finished form of new system,…
Haiku 18 A (autumnal equinox) — system’s release of year, from that moment sources can accept only bug fixes and finishing what is started but not finished yet, no new things must be added.
Haiku 18 W (winter solstice) — from this moment system accepts only bug fixes, if some things not finished they goes to ‘experimental’ of that release; start of new branch of Haiku 19 next year (NY), new system formulation. Much older Haiku (17, for beta and alpha) stop receive fixes (after Haiku maturing, cycle of supporting system must extend to 7 or 10 years, that means that after releasing R1 it must receive important updates and fixes for 7 years or 10).
Yours input in perfecting cycles are welcom.
1 Like
I think with respect but you are wrong there.
Let me clarify then.
We could take any nightly build, rename the file, and go “there, have your release”. It would get some media attention, which is a good thing. But people would soon find out about the many problems with it. As a result, two months later we would be telling people to use the nightlies because they are better. So, the release wouldn’t accomplish anything in terms of providing a stable platform for developers.
The important things in “making a release” is not the release, but the making. It is all the work that has been going on for years to set up proper tools, and get everything running smoothly. As a result of all these efforts, we will be able to ship something great, a stable platform that devs can base their apps on. There will of course still be bugs, but we will have a plan to get them fixed and the fixes sent to our users, without bringing in regressions at the same time.
If we are succesful in this, then yes, a release is a good thing. Otherwise, you could consider any of our nightly builds to be a release, but that won’t get you any further than the current situation.
Also, I still don’t believe that making a release will suddenly attract dozens of developers who were just waiting for it and refraining from touching Haiku because “oh no, it’s still in alpha”. If people are interested in Haiku, they should be contributing now and sharing their nice apps 
1 Like
I agree.
In fact, until we reach a stable release process, I’m for removing Alpha 4 promotion on our website and instead turn people to some nightly-of-the-month-or-something image.
That would attract some small attention (but small is better than none) while reducing the “in-alpha-state-since-N-years-oh-that-bad” factor we kinda suffer lately.
2 Likes
“I’m still a bit confused as to the need for FSF endorsement.”
It’s not something anyone needs, but if Haiku did meet the criteria to be added to the FSF’s list, maybe it might help some more people discover the project. I just thought it would be a shame if Haiku had replaced all its proprietary bits, and nobody had bothered to check and update the FSF folks. So, I asked for some clarification in the OP.
Since there is proprietary software in Haiku releases, and the devs have no plans to change that, it’s not going to qualify. No big deal.
“The open source community existed long before the FSF.”
True, the first versions of what became the BSDs were released before the founding of the FSF in 1985. But it wasn’t until 1988 that any part of BSD was released under the BSD license. For the record, all of this happened before phrase “open source” was even created (Christine Peterson coined it in 1998). More info about these historical milestones, with links to primary sources, can be found here:
https://www.coactivate.org/projects/disintermedia/free-culture-timeline
This thread seems to have moved on to a discussion about release schedules, so I’ll leave it there. Thanks for your reply.
I think this discussion about release schedules is a very valuable discussion for the Haiku community, far too valuable to be buried at the bottom of this thread on “making Haiku free software”, where interested community members may not find it. Can I suggest forking, and if possible, moving the comment about release schedules to its own thread, under a more pertinent title?
2 Likes
I’d go even further: The Haiku devs should continue the thread “R1/beta1 (finally?)” to hash things out among the people with the knowledge and the power of decision. When the path to the beta has been fixed, inform everyone with a nice crisp blog post.
1 Like
I’ll throw in an “aye” for removing the alpha release, in favor of strictly releasing nightly builds until B1/R1.
I’m fairly versed in computer history as well. Everything you said is all well and true. I’m well aware of the origins of community jargon. While it didn’t have the modern name of open source until much later, the concept of sharing source code is about as old as computers. Yes, it even predates the modern BSD lineage you mentioned.
I highly doubt licensing has anything to do with popularity or lack thereof. Even it’s heyday, BeOS was a small niche, known only to a few geeks and used by fewer. And the exact same arguments were used back then as they are now as to why or why not yet another OS is needed.
I think the point is to focus on building the system instead of focusing on the license. A complete, usable system will do far more to increase Haiku’s popularity than the fanciest, dandiest license ever will.
One thing to think about: would having a sudden and sizable influx of new devs really be the best thing for Haiku right now? There is a rather strict set of guidelines for coding the main system. This is a good thing. Would it be a good thing to flood our current devs with getting a metric crap ton of new coders up to speed on project guidelines?
1 Like
On advertising nightlies: to me this is like giving up any hope on progress towards R1. But if that’s the way most people prefer, let’s go with it. No releases to support, it would be less work for the devs. But it is in contradiction with the “we need a stable platform to attract devs” idea.
As for attracting new devs: yes, it definitely is a good thing. There is way too much work for the current team, taking care of both the OS and many of the applications. And we are quite welcoming to new developers even if we are strict on following the coding guidelines (like any sane probect, I’d say)
1 Like
We like philosophers, in fact someone periodically come here to make philosophy.
But feel free to contribute also some work to this project. Ideas are good, but sharing an apple may be useful too.
1 Like
Right now I’m in a hardware and social situation where net connectivity is giving me fits where it’s next to impossible to get much done in Haiku or any OS for that matter. I look forward to getting some real work done once I complete my current move. In the meantime, here’s some philosophy. Cheers. 
PS. I have submitted a documentation patch recently that fixed a user guide on GRUB, which was swiftly updated. Small and meager, I know. But it’s something other than bare philosophy. 
Thank you, every little bit helps.
1 Like
The licenses are important, because they determine whether Haiku is a free code/ open source OS, which can be freely distributed, or a proprietary OS with some free code components (like Windows, MacOS etc), whose distribution can be controlled by the copyright owner(s) of the proprietary components. What’s the point of building yet another proprietary OS? If Haiku wants to compete with GNU-Linux as the pre-eminent free code desktop OS, which I agree would be awesome, it first has to be open source (all of it).
We just ship a binary firmware for wifi cards for user convenience (this is easily removed if you don’t want it) and suddenly we are as bad as Windows or OS X. So our 17 years of effort writing free software are worth nothing?
7 Likes
Wait, what? When did Haiku go closed source? OMG OMG OMG! Alert the FSF! Sound the alarm! We’re doomed!
1 Like