I’ve found several YouTube videos reviewing Haiku (even if it’s just a brief mention) and there are several YouTube channels I could try emailing to see if they are interested. For the existing video reviews of Haiku, I could try emailing the channel and asking if they wish to review Beta 2 (if their review was a while ago), and for the channels that only gave us a brief mention (i.e. TechQuickie) and invite them to review Haiku in-depth.
I have thought about posting on several volunteer sites to promote the amount of opportunities available here at Haiku. Haiku Inc. could always do with more help, and our developer team needs more hands on deck. By letting more people know about Haiku opportunities through volunteer websites we may attract more volunteers.
On the development side of things, maybe the following as a Read the Docs ad could work: We need C++ developers! Volunteer in a friendly open source community and help us build Haiku.
There is an 80 character limit for these ads, so we have to keep it short and sweet.
I have an idea to make a “reviews pack” and maybe a “press kit” to help the press and any potential reviewers. It will take some time though as I have to gather information and any promotional material that Haiku currently has.
Somebody mentioned earlier that we are not selling anything, so marketing is perhaps not the right word. Promotion might be better. (I know that I have used the term marketing myself!)
One of the reasons that I keep boring people to death on the subject of structure is that it would be great if somebody could be assigned the role of Haiku Promotion Coordinator (or whatever) and that person could then - as the title suggests - coordinate promotional efforts, and be the person that people offering to help could contact and look to for support (with promotional materials, facts and figures, records of what has been done before, and what needs to be done, contact details, etc…).
As jt15s says, (s)he is going to have to spend time gathering all this information. It would be great if that task wasn’t necessary. Let’s hope that all (s)he finds can be stored somewhere that other hopeful promoters can access, so that the wheel doesn’t have to be reinvented time and again.
For starters, @waddlesplash, @PulkoMandy and @humdinger are responsible for press inquiries already. The thing is, they have simply volunteered to take up the responsibility to be press contacts, but they don’t have a formal title. They are all Haiku developers as well. Sure, “Haiku Promotion Coordinator” sounds good as a title, but in real terms, we don’t really need a formal position. I’m more than happy to fill this position informally, but we don’t need the whole “Official [blah] Coordinator”.
Thankfully I have found artwork and icons I can use on Github - that gives me a good base to work from. I am thinking of passing the completed kits to the press contacts so they can forward it whenever the press inquires about anything.
You are very attached to titles for people to put on their business cards, it seems.
There can be a marketing/outreach team just as there is a development team. Since there is none currently, the team will start as a single person. Then it can grow, and the people part of it can decide between themselves how to best organize their team, if needed.
Just as with development work, there should be some form of review process. At least initially, the development team will want to have an eye on it to make sure what is produced is in line with their vision for Haiku. If the marketing/outreach team does a good job, we will trust them, and let them do their things more freely then
Titles perform various tasks, not always useful, as you imply.
But one of the useful roles is to act as a sign-post. If somebody is responsible for something, then having a title announces the fact, and, like a light-house, shows people where to go.
The fact that virtually all successful and effective organisations do use titles suggests that I am not alone in thinking there is merit in them.
But I totally agree with your thoughts on how the role of teams in Haiku should develop.
I prefer if you use the forum and mailing list (then I know that some other people can reply if I’m not available, less presure on me)
The main way we are organized is: don’t contact a single person individually. Never. This is not how we work. So, the titles are attached to mailing lists and similar tools. Want to talk to the developers? Use the haiku-development mailing list. To the inc people? Use the haiku-inc mailing list.
The responsibility is one on anyone’s individual shoulders. We cannot afford that, both in the stress level that would result for that person, and for the risk it would put everyone else at if said person becomes unavailable (since this is not a paid job, and availability of people can vary a lot, and for many reasons).
There are just people doing the work at any given time. They can come and go as they want (and they should make sure they can come and go as they want, by having other people being aware of what they do). Yes, this is possibly confusing and not optimal. But, it is very resilient, and I think that’s an useful thing to have in our case.
One of Haiku’s biggest problems is the perception that it is moving slowly, at least based on what @PulkoMandy has said in the past. Haiku is also in need of new contributors coming on board, for code and other things like documentation.
Perhaps a good way to address both issues is to have weekly blog posts detailing changes in Haiku, talking about plans for the very near (and not so near) future of Haiku, events, etc. while also encouraging others to contribute.
The inspiration for this comes from KDE’s Nate Graham, whose blog has been detailing weekly changes in various KDE projects through the This Week in KDE (formerly This Week in Usability and Productivity) series of posts. These have helped make KDE more transparent and accessible to a lot of people, in addition to attracting new contributors and people interested in their projects.
While it would be ideal if a Haiku equivalent will be written by one of the devs, this doesn’t necessarily have to be the case. They prolly will have to be consulted at certain points to make sure that what is being written is correct, however none of them would have to actually write anything themselves.
We have monthly reports on the website. There would not be much to say in a weekly report and it would be too much work to write one every week, I think.
I try to do some Haiku marketing in my free time, but it’s bound to be limited because of reasons:
For pre-release software, development material is generally the primary source of communication. When the development goes slow, the amount of material to convey is limited.
Once you convince a non-developer to install and use Haiku, it’s not so ideal, because the user is frustrated in the end, due to bugs and stuff. Which is normal.
From my point of view, Haiku marketing lacks development material. What are these:
Blog posts about various development challenges
Short videos/tutorials/blog posts about Haiku development. These will help greatly for stranger developers to get their feet wet.
Lack of easily-consumable material, e.g., a tweet of a newly ported application, or a tweet about a commit that fixes a very old bug etc. I’ve been told that this is intentional.
For the non-developer folks out there:
Haiku website is not the most intuitive website. If someone here has web development skills, a simple but intuitive website with nice artwork will go great lengths on keeping a visitor home. For instance, if you have a nice shiny HD display, Haiku screenshots on the website is terribly outdated, it might be a good start.
On the Twitter side, Haikunauts is doing a good job conveying Haiku related marketing material in English language. If you are interested, sharing content with the account holder might be useful. On Reddit it is easier, sharing content on r/haikuOS and cross-posting to other related subreddits would help.
That’s fine. A defined mailing list would work as well, though it would be nice to know that somebody takes responsibility for ensuring that enquiries are replied to, and knows where to find all the material mentioned earlier. But we don’t appear to have a Marketing/Promotion mailing list at the moment unless I have missed it.
These all sound like good ideas, and maybe I could set up some sort of written interview (that focuses on development challenges) with some of the developers and post it on the blog.
We do have a couple of getting started docs, such as the “Gentle Introduction to Haiku Ports” series, the intros to writing drivers, but I agree we need more. Not too sure what topics we should write these on, though. Making tutorial videos is a good idea too, but we need someone who a) has the knowledge and b) is willing to talk and explain things in a video.
With the problem of easily-consumable material, we need a dedicated person to man the social media accounts, post regularly and perhaps answer any questions people post on social media platforms. It would be good to have someone step in to do this.
On the topic of development and attracting new developers it would be nice if we had an easier way for people to try development that is as easy as possible. To me that might mean a Virtualbox image and clear instructions on how to set that up easily on any OS. This image would include a fairly recent copy of the code which is easy to update, and clear instructions on how to push patches to Gerrit. Maybe some sort of “Welcome” application that sets everything up.
Maybe as part of that there is a simple bug in something like ShowImage (maybe in a special branch in Git that we keep rebased, or as a diff file that gets applied when the virtual machine image is built), and the first challenge for someone is to fix that bug, rebuild ShowImage and test the new copy. Maybe there is other similar tasks and we walk people through how to test those and maybe even how to build a new haiku.hpkg and update the OS in the VM.
I know there are some issues here like slower performance of Haiku in Virtualbox, but it still might be worth trying it out.
I know I find it hard to get back into Haiku development sometimes because I have to go to my special machine which has all the Haiku stuff set up, and then I have to make sure the buildtools are updated, etc, etc. I feel like reducing the friction on all that could be helpful to get more developers. Though maybe PulkoMandy will say we already have enough “drive-by” patches on Gerrit…
Sounds like a good idea - we could consider using Vagrant - which is like a VM image but easier to set up and preinstall any tools. Vagrant images are also compatible with multiple VM platforms. I’ve been trying to wrap my head around how Vagrant works since I’m also working on a Vagrant image for another FOSS project, but apart from reading the documentation not much else has progressed.
Speaking from experience here (for me, Virtualbox is the only way I can try Haiku), the performance is bearable but might not be good for a development situation. Software update always fails, though, and there is a bug I filed with the Installer a while ago.
Yeah, it would. I might try at setting up a Vagrant image, but I’ll need more specifics on what tools the developers need to develop in Haiku, and someone (a willing app developer) can work on a “Welcome” app for developers.
You probably need to switch to “Intel MT Desktop” network card type in the VM settings, if you haven’t. (Otherwise your network is probably just slow, and we should really fix that retry bug.)
Yeah, I am on the Intel MT Desktop network card. My network is pretty fast for tasks on the host system, so I’m not too sure what’s going on. The thing is the Software Updater (and pkgman) aborts all updates whenever something goes wrong so it’s impossible to install any updates for me.
That’s one of those bugs that I have been wanting for fix for a while but haven’t yet, and apparently neither has anyone else. I will try to work on that this month, probably over the Christmas break. It causes problems for a lot of people though that is really terrible that is never works for you.
The setup for different type of tasks is often quite different. For writing apps, you want to run inside Haiku. For writing drivers, you probably want your git checkout on Linux, and run a rebuilt Haiku in qemu. I don’t think there is a one-size-fits-all VM.
The steps to set up the environment for Haiku currently would be (in parentheses, the changes with a “premade” image):
Download the image from the website (this would still be needed)
Create a VM and add the disk image to it (probably still needed - we stopped shipping separate VM images because it just doubles the disk space usage on our servers)
Run Installer and install to a larger disk image + enable the devtools that are in optional packages (could be avoided if we had bfsresize merged. It’s been waiting for someone to do code review for about 6 years now)
Get the sourcecode and install the Gerrit hooks (could be included, making the image a lot bigger, again wasting disk space on the server)
Configure your git: username, email, ssh keys, github account, gerrit account (would still be needed, and even worse, if you start from a fresh VM everytime instead of updating your existing setup, you need to redo most of this)
Fix a bug (would still be needed of course, and I see no point in asking people to fix a fictional bug - in Outreachy applications we asked them to add their names to AboutSystem but it resulted in annoying noise on Gerrit, so in retrospect it wasn’t a great idea)
Submit the patch to Gerrit (no change here)
Wait for code reviews (and that’s the main problem here, it will probably take a few hours/days and the first round of review will be boring coding style problems - we need a robot providing immediate feedback about this)
Iterate on the review, fix the changes, submit new version of the patch
And then, if you only contribute once every few months, you will have to redi this all from scratch? When you could just run “pkgman update” and be rolling with your existing machine?
Sorry but I think you are making excuses for yourself for not having time to contribute here
Even if you don’t have an Haiku machine at hand, there are many other ways to help. It can be improving the documentation about Gerrit and submitting patches if you are not happy with what we have now. It can be reviewing some of the patches submitted to Gerrit. Even if you don’t do any testing, having a look at the patch and checking the coding style is of some help (ideally we would have a bot doing that, Owen is working again on haiku-format and I hope we can soon get it working well enough to deploy it there).
These days a lot of my Haiku work is during lunch break at work for such tasks that do not require a development environment. And on week-ends I can work on larger things and actually compile code.
Long story short, I guess: quality over quantity. If you can’t be bothered to do the development environment setup, you probably won’t bother to fix coding style problems in your patches, either. On the other hand, improving our onboarding docs is a great idea. Probably we should see about integrating the wiki pages created for GCI (“install and run haiku” and “compile haiku”) into the website documentation, or something like that.
As you can see it tooks 3 weeks before someone tried it. Maybe it would help if more people were looking at the patches on Gerrit and reviewing/testing them (or at least, knowing that they exist?)
