Open source projects should run office hours
simonwillison.net
simonwillison.net
Maybe "Office hours may be a good idea for open source projects"? This would not suggest obligation.
In general, fact that someone created or maintains or supports open source projects should not be considered to create any obligations beyond lack of malice and abuse.
I am not obligated to support any bugs, create any features and it is perfectly fine to delete all my repos at any time (unless I declared otherwise).
I am also not obligated to support anything, help with anything, there is no guarantee of uptime, office hours, resolving issues or anything else.
If you want obligations, guarantees or anything like that - feel free to hire a given developer.
Many such things are good ideas and some people may decide to promise them (if you describe something as secure then you declared to handle security issues timely). But I reject idea of being obligated to do any of above.
It seems pretty obvious that the author doesn't intend to coerce anyone into doing anything.
The Law of the Topmost Comment says nothing about the relatedness to the OP's article[1]. I would suggest you research the topic further before making any more ill-informed comments on it.
If your argument holds, I would expect my agreeable comment of mine to be downvoted or replaced by a comment possibly critical of your viewpoint.
Although in general, you can't expect replies to other comments and comments on posts to follow the same patterns.
One such use of this is when someone posts an article they have some control over, knowing how the title biases or primes a reader can be very informative if they need to make a change because of an unintended effect, given the chance of communities entirely disconnected from hacker news viewing and possibly discussing the article.
But he also points out it'd be an easy opportunity to up-sell some people on a consulting session if they want features he isn't as interested in developing :)
What makes you think this comment is doing anything except providing positive feedback?
>It seems pretty obvious that the author doesn't intend to coerce anyone into doing anything.
Subtext is weird and dangerous. Using more accurate phrasing costs nothing and potentially averts problems.
It doesn't address any of the points mentioned in the article, and in fact, doesn't address the general theme of the article.
There is no subtext at all, the article is simple and clear, and one would be hard pressed to think that the author is trying to force anyone to do anything while reading it.
The author did actually rename it now that it suddenly has a much wider audience! It's now "Open source projects: consider running office hours"
Given that, I think we can safely assume his original audience (blog regulars) didn't mind the title. I realize accuracy is only a small effort, but it IS an effort. Why spend more time on it than is necessary for the audience?
I have forgotten about this guidelines. I will try to follow them better in future (ling is in footer and leads to https://news.ycombinator.com/newsguidelines.html ).
Though my comment was at least attempt to be "this title if taken alone is problematic, maybe changing it would better" not "you are awful person and your title was bad".
It is likely that I should be formulate it better and spend more time on making it (though I admit that I expected that it will be ignored rather than upvoted to the top comment...).
The qualifier "consider" is very important but was removed by the OP.
Pro tip: if you don't mean should, don't write should.
Avoiding reasoning about the nature of your beliefs (and why others might be subject to those beliefs) is a weakness in thinking.
"Should" is also the easiest way to create a clickbait headline to argue about because there are so many individual interpretations and following justifications of "should".
It is part of things personally irritating to me, and something what is biggest threat to small open source projects that I like.
People are mistaken in thinking that having an open source project implies any obligation beyond lack of malice.
And people tired by dealing with that are one of top reason why open source projects disappear or are never created.
So skimming the title it quickly I read it as "Open source projects should run on office hours" since my mind filled that in, kinda implied that someone in another part of the world should adjust their life hours to contribute to OSS.
(Yes after reading the article i realized that it was wrong but this is about the title)
> you know, the kind of hours that people typically work in an office.
It's exactly the same thing. There is no difference. This guy "works" in a home office on his project and he does so by talking with contributors (his customers essentially) instead of just sending a message on a mailing list or by posting on an issue tracker.
Where do you see the difference between this and a lawyer being open from 9-5 for customers? They are still his office hours and "office hours" primarily matter to outsiders who have to schedule an appointment.
For example, I work on a project that heavily depends on "library foo". The guy who wrote "library foo" (who is an employee of my company) holds "office hours" for one hour every Monday, where he commits to being in a Zoom call that other employees can join to discuss questions about "library foo". That does not mean he only works for one hour a week.
To a student with no professional experience, "office hours" are posted times when a professor is available to further mentor and guide a student. "office hours" are designated times outside of the scheduled class times and professors are generally required to provide them so others can benefit.
To a professional and others with white-collar jobs, "office hours" are hours are times when an employee must be seen by a manager to be considered working. Times outside of the scheduled work times are called "outside of office hours" and employees are generally expected to provides them so others can benefit.
Still, I am deeply opposed to formulating in ways that suggests any form of obligation/entitlement/expectation.
Though I expect that in many cases it would be a good and useful idea!
Sadly I can not edit my comment, in this case it would be useful :(
"I’d like to encourage more open source project maintainers to consider doing something similar."
Then I read the article and it IS using "should" in the sense of "I found this beneficial, you may too" rather than "this is an obligation".
That was my first impression too.
Had to think that M-F 9-5 would not be enough for some projects, in total hours alone not just to accommodate different time zones.
Doesn't seem so bad to me, my "office" is staffed 24/7 and I always look forward to solving a user's million-dollar problem with a single phone call at any hour.
Even if it's not one of my regular clients. That's how some of the best ones got that way.
See also :)
But, if we're using IETFs grammar:
"Should" here implies unless you have a good reason, you should do this. For anything related to open source (which is based on voluntary contributions and practices), that's a bad choice.
"May" would be a better pick here, to remove the assumed obligation to run office hours.
And the article talks about the purpose being for gathering feedback (think UX sessions), not for gratuitous support. Meaning that goal is for the project maintainer to draw benefits from others donating their time.
Personally I think this a really clever idea
>Update 5th March 2021: The original headline of this piece was “Open source projects should run office hours”. This was being misinterpreted as yet another demand for free labor from open source maintainers, so I changed it to “Open source projects: consider running office hours”—less pithy, but it better reflects my actual message here.
In theory it could be a way to fund open source dev.
It's more of a market research exercise than freemium consulting.
That's not to say it couldn't also turn into a profitable exercise through up-selling consultancy, but that's not the primary goal.
I feel the gem in this article is the freemium idea for consulting on open source development.
Note that the GPL specifically does not require publishing the source code, or having to distribute it along with the binaries. It allows the alternative of only providing the source code upon request by any third party, to that same third party.
No, this requirement applies only if you are using somebody's else GPL code, and it's meant to allow other developers and users to benefit from the work done.
It does not apply to the original author because the author owns the copyright of that code.
Short version of your obligations if using GPL as a license: https://tldrlegal.com/license/gnu-general-public-license-v3-...
Yes.
> not a "open source" one
It is also an open source license.
Classic SHOULD vs MUST.
This comment thread is being upvoted because.. wait we're not supposed to suggest someone didn't read the article here are we :)
I think we need to separate open source products and open source projects. A product being the main product of a for-profit company or a marketing tool by a for-profit company and a project being something that someone released just to be nice, to show off, etc.
I literally tried to use a dev tooling SaaS service their offical integration broke my build in 3 different ways. What makes this all the worse is that the integration shouldn't even be enabled in test mode. It was configured not to, but still it broke my build in 3 different ways. I literally decided to use a competitor straight away. But wanted to at least let them know of the issues. The tickets to their offical integration were responded to by volunteers. After a few days I noticed no employees of this company that raised 65 Million had shown up to look into build breaking bugs in their dev tooling product. I tweeted that they were relying on volunteers to do support. The CTO said that was absolutely not true then said with open source people will volunteer and that is a benefit. So in the one tweet is contradicted himself, weirdly this tweet was well liked. They went on to use the fact I am free to use a self hosted OSS version of the product, support is a bit much to ask. My issue wasn't that they had volunteers helping out, it was that it was literally only volunteers. The volunteers rightly pointed out they're volunteers and said the company provides paid support. Then went on to say that the company won't be able to help since they write and maintain the product and they're the domain experts for this area. Again, relying... Both the issues ended up being closed because "We don't think it's our code and we can't reproduct". Considering these are build breaking bugs that you will encounter while onboarding to the paid product that response is not acceptable. It is acceptable in this is free and unoffical.
Open Source is not an excuse to be unprofessional. Saying "Well you don't have to use our paid product you can use OSS" when someone points out the support provided for the paid product is unprofessional and is not a valid excuse for providing crappy support. Saying this is GitHub and not a valid place to expect a company to support their techincal products is not professional. As an industry, we need to step away from the unprofessionalism that open source has brought to the table. People literally have talks saying do open source it's good for your professional career and in the day tweet complaining and asking if an open source project they use to boost their professional career is dead.
Honestly, I think free open source for companies should be a thing of the past and we should move towards paid license with paid support. The number of companies that will be completely screwed if one over worked guy in Milan decides to stop working on a hobby project is unacceptable.
We should be creating obligiations on things that are clearly for professional gain and putting a price tag on those obligations.
/rant
Compare that to the usual issue grind. You feel compelled to respond as fast as quickly and maybe even spend your whole day because you know that the backlog will grow worse tomorrow.
Adam Jacobs of Chef was running a Puppet consulting company (hjksolutions). He ran into a bug (#1010) that he couldn’t solve and used up a ton of Luke’s time. Luke worked hard on it but couldn’t reproduce it and after devoting a week or two on it told Adam that he was the only one with this problem and would need to pay him as a consultant for any further effort.
Adam was (is) an incredibly pushy jerk and demanded that Luke, who wasn’t making a penny off of Puppet, put his life on hold to fix this for Adam’s customers.
Luke basically said “fuck you, pay me” so Adam started Chef (a billion dollar company).
User’s sense of entitlement is powerful.
People are getting used to the freemium model popular in software, apps, games, and the "free" model of gmail/youtube/facebook (where you pay with your privacy).
That is not what the article is suggesting.
From the article -
>> anyone can book a 25 minute conversation with me on a Friday to talk about the project. I’m interested in talking to people who are using Datasette, or who are considering using it, or who just want to have a chat.
>>A challenge of open source is that it’s easy to be starved of feedback. People might file bug reports if something breaks, but other than that it can feel like publishing software into a void.
>> Hearing directly from people who are using your stuff is incredibly motivational. It’s also an amazing source of ideas and feedback on where the project should go next.
I think that's really a fantastic suggestion.
I’m still a little puzzled by exactly what is meant when people and orgs offer an “office hours” concept.
I’d love a clear but concise definition that’s not simply “like office hours in university”.
It means “I will always be available in my office during such-and-such hours every week, for anyone to come and talk to.” I think it’s normally a walk-in affair rather than involving making appointments. First come, first serve, but now you don’t have to go through the bother of making appointments and such and comparing your timetables. Makes life easier for both parties. This article is talking of making appointments, but most of the benefits still remain of having a known block of availability.
A few of our lecturers had "office hours". It was a new phrase, and invariably they were younger and had worked in US universities. We could drop in between 3 and 5 one day a week to ask questions.
We thought them snooty.
The other faculty staff had an open door policy.
Now I'm their age, I appreciate how sticking to office hours helped these researchers to be productive. But as a student, open door flet more friendly.
Office Hours is a way of saying I will DEFINITELY be in my office at my desk during this block of time.
(That's how I learned it can mean something else than "when the workplace is open". English is not my first language.)
Mostly applicable to academia, because who the hell has their own office right now.
UK if it helps but also I only work for smaller startup sized companies maybe it's a corporate thing
I suspect it might also be a synonym for "working hours" or 9-5, aka a job.
Easy, request they have a quick 5min feedback chat with you and you'll bump their issue on the priority list.
The tautology that if you want feedback then you want feedback is true. The rest is bullshit.
Apparently putting "DMs open" in your twitter bio is an excellent way to meet new people. Also, tweet (often!) about what you're working on. Post lots of questions, notes to self, and screenshots or videos.
To get followers, you'll need to go inject yourself into conversations. That seems to be the most reliable way to get noticed.
We also run an ML discord server and do informal office hours for people working on various ML products. It may sound cheesy, but I try to emulate what pg would do in a YC office hours session. It seems to keep them pretty focused.
So, yes! Glad to see office hours are becoming mainstream. Try it out; you'll probably be surprised.
Wrong direction for whom?
The actual technique will take a month or so to execute, but the core idea is pretty much guaranteed to work.
I've been working on getting GPT2 to write poetry and I've made a fair amount of progress by fine-tuning on a poetic corpus. Then during generation I constrain tokens that would break the style of the previously generated text. It has already produced a few samples that are surprisingly moving. Here's one of my favorite cherry-picked samples which was generated with a prompt of "The sea grew":
"The sea grew angry, and turned to fire,
And all the stars did mourn for earth and sky.
The wind did moan, as when one who hath lost
Love through some evil counsellor, hears
A lamentable voice that sobs and sighs;
Or when some old sorrow's semblance doth appear"
It makes me think of someone describing the meteor strike that killed off the dinosaurs.
To achieve this, I simply perform analysis on the tokens as they are generated, then turn off the logits for tokens that would break the current flow. I'm currently working on enforcing meter and rhyme using a similar approach. I've also had success with creating checkpoints by pickling the model state at a good stopping point, like at the end of a line, then letting the model do its thing and reverting back to the checkpoint if it produces something that doesn't match what I'm looking for.
Assuming that everybody has the luxury to have additional office hours available is a bit far from reality in my opinion.
I mean, if you can offer office hours for an open source project you probably are already so popular that you are able to work on it fulltime, right? And if you're not that popular, you cannot offer office hours due to your daytime job; as you would have to decrease the rest of your remaining free time that you probably need to sleep and eat.
In exchange for that I get extremely high bandwidth feedback from real users of my software!
Per the article, he's not saying you should work on the project during office hours. Instead, to get feedback from users, he's allocating some time where users can have a talk with him about the project. He's calling that 'Office Hours'.
I think that it's a really valuable suggestion.
Of course the latter is still time spent working on the project, but it's certainly not in direct conflict with having a full-time job paying the bills.
It's a useful piece of advice for people who are in need of such feedback, and can afford to block off a bit of time on their schedule on a regular basis. It doesn't apply to everyone, but it's a good trick if it does apply to you.
Are you certain? I'd think most open source development is done by paid developers, on company time.
"I’d like to encourage more open source project maintainers to consider doing something similar"
It's a matter of fact that many people (myself included) form opinions based on the headline without reading the article - so I wish I'd worked a little harder coming up with a headline that better encapsulated that message!
"Open source projects should consider office hours" perhaps?
I'm going to change that headline on my blog now.
This might be exacerbated with non-native english speakers which you'll see a lot around here.
The new title you suggested doesn't fix anything (at least for me it doesn't). Maybe consider using more commonly known terms to refer to the fact that your opening up you calendar to video calls with anyone that shows up?
I've added a note about the better German term "Sprechstunde" to both the article and my Calendly description: https://calendly.com/swillison/datasette-office-hours
People always expect free Github replies and responses to PRs and issues. But it is almost taboo to expect free consultation and office hours. Great way to make some money if you have developed a popular library!
Because I sell license keys to unlock features, it allows me to provide generalized support and quick bug fixes via the discord for everyone for free. If people need help with integration in their specific code base then that's when I ask them to go through the "consulting route" - if it's quick they use otechie. If it's more involved (1+ days) then we work out a contract arrangement.
I hardly get any clients through these means but it does put a clear value on my time which results in the community appreciating the time and effort into the project and the real time support (via discord).
Paranoid me is a little nervous about putting up a scheduling link publicly, but here goes:
I work on Typesense [1], which is an open source alternative to Algolia and an easier to use alternative to ElasticSearch. If you want to talk search and/or Typesense - DMs and Office Hours open: https://calendly.com/jason-typesense/typesense-office-hours
I need to find some place/way to use this. It looks interesting.
https://sfconservancy.org/blog/2020/mar/12/virtualchat/ https://sfconservancy.org/blog/2020/jul/29/virtualchat2/
I think the Reproducible Builds folks were also planning to have an office hours, not sure if it lasted though.
https://lists.reproducible-builds.org/pipermail/rb-general/2...
I love this.
And no, I don't think the issue was that no one had any questions. We got plenty of questions via Gitter chat, mailing lists and GitHub issues. We advertised the office hours on the same Gitter chat and mailing lists too.
We also tried moving the time around to various times of the day, also with minimal effect on attendance.
The only thing we had any success with at all was convincing a few larger users to give short presentations on what they were doing with the project and what their pain points were. When we did this, that user would come, but few other, non-project members would come.
I still really like the idea, but I am not sure that the open source community really wants office hours.
Booking slots helps emphasize that this us a one-on-one opportunity for a conversation - not a situation where you might feel awkward that there are several others on the chat who already know each other.
It also sets up a small obligation that you'll actually show up, since if you reserved a slot it's rude to cancel at short notice.
(The course is behavioural economics and this is a kind of interesting behavioural phenomenon).
It hits the big issues of talking to your users and probably acting as a good filter for finding contributors.
I am slowly reawakening some projects from deep freeze, and when / if they garner any users I will try this ... which of course is the downside of the idea. You need users :-)
[0] https://knative.dev/community/calendar/ , though check the @KnativeProject twitter account tomorrow because the video links are getting switched from Zoom to Google Meet to make it easier for more folks to join.
But I won't and I don't feel any sort of obligation to do so, so I don't think 'should' is really appropriate here.
So many conference talks' second slide is a "numbers" slide wit how many github stars, active contributors and other vanity metrics. It strikes me that the point is not just to convey that the project has an ecosystem behind it (with the implication there being that you can get free feature development and support), but to hit some sort of weird OKR-ish goal set.
Or it's because in the end people like being popular and always have. Social standing, social cred and all that. I mean, look at all the people who obsess about their instagram or twitter follower counts. Being a FOSS developer doesn't remove all the usual human drives and desires that most people have.
> instagram or twitter follower counts. Being a FOSS developer doesn't remove all the usual human drives and desires that most people have.
This is corporate influence. Those companies are manipulating that innate status-seeking behavior and amplifying it. In my opinion most F/OSS developers or most creative subcultures clout chase in different ways but it's usually not so overt and it certainly isn't trying to show "hockey stick growth" on slide #2.
I'd argue that for most F/OSS developers making cool (and maybe some overly complicated) things used to be the main way to clout chase, until some corporations came along and helped us "connect" but also sought to make profit from those connections and encourage the connecting.
Let's take HN for an example -- how do people clout chase here? HN's major moderation innovation/advantage is that they've tried their hardest to make clout chasing here equivalent to submitting interesting projects/products/thought/discussion. I'm sure they have the metrics internally, but I just never see HN bragging about how much "engagement" they get.
Every once in a while I go back and think of the origins of the F/OSS movement -- the idea is insane on it's face. Labor to make software, then give it away, and license it in a way that anyone who uses it is also forced to give it away? Who would fund/contribute to such a thing? How insane I think that concept is assurance that I consider myself a capitalist on the economic policy spectrum.
I know that this is kinder than just firing someone outright if the project they were on failed, but the thought of it makes me feel uncomfortable.
Is it more because RedHat carries itself like a consultancy than other large enterprise businesses? Is it that the possibility of being let go after a large project that you performed a relatively specialized role on feels just about right for a consultancy, but not for a business that carries themselves like a long term player? I feel like I'd expect this behavior from Pivotal for example (not implying that they'd do that).
This. Someone there could hire me onto a project that fails for some reason out of my control, and then, because I’m older, I wouldn’t get picked up by another team.
I don’t know if project-pickup retention is still how they operate; it’s several-year-old anecdotal information from a past worker there before they were acquired by IBM.
Datasette is a great project and in the traditional F/OSS sense is delivering an intense amount of value off the backs of passionate volunteers (for better or for worse) -- Thanks for making it and persisting in making it better.
Office hours working great for Datasette is fantastic (thanks for sharing) and you arguably an objective benefit to the world with the amount you've already created and released. I don't think it's right for every single open source project but more power to you. This riff definitely wasn't meant to poo-poo your approach.
I don't mean to exaggerate or make an unfair comparison, but I had very similar experiences 15 years ago when I was considering being interested in trying to get a contribution (any contribution) merged into the linux kernel. That process is so off-putting I lost interest. Granted, kernel development is an entirely different beast and I understand (better now after a career) why it's partly the way it is.
I think I'm rambling - tl;dr: this sort of attitude is off-putting from open source, even as someone who's been in software a long time.
It really depends on the nature of your project and knowing the limits of async communication. If you have lots of contributors, it might help.
Office hours for an office-like job sound totally reasonable.
The message I'm trying to get across here is that I've found office hours to be incredibly valuable, and other maintainers should seriously consider adopting the same trick.
I also tweet about a lot of React stuff:
https://twitter.com/acemarke/status/1365874077177700361
https://twitter.com/acemarke/status/1366102388399087619
and on rare occasions, things that are _not_ React or Redux related :)
I thought they could be fun, but you really had to be on your toes to do it well. And you need to set really clear expectations on what's doable in the short time.
In the end, however, it can sometimes just be easier not to charge. If you do larger projects, these short little meetings can be a primer for filtering potential clients while giving the potential client a taste of what working with you is like.
On the flip side, if you work on a project that’s already popular, you don’t want to be spending all your time doing free Q&A. Especially not for enterprise folks who have money but aren’t paying anyway. This is how maintainer burnout happens.
There’s a sweet spot here, which will vary by project and by maintainer.
Now I'm wondering if I should make it available for the lower tiers as well.
We link to it in our readme
https://gitlab.com/jam-systems/jam
(can be improved)
I wonder if there is a better name for the concept that works for international audiences and people who don’t know the concept from academia.
For larger projects I can also imagine other formats like “show and tell” or “Q & A” where people submit questions (maybe even with donations or paid to create an income stream for the people working on the project)
It's not an easy run don't get me wrong, but it's gotta be easy than using up 25 minutes per person. Open source? Open meeting!
Grab yourself a copy of OBS. Get on Twitch/YouTube!
E: made it sound less of an ad? Idk that's the quickest I've ever been downvoted here haha. I watch open source coders stream once a week to like 200-400 people if the concept sounds bollocks.. That translates to beyond ramen for your Silicon Valley types and actual cost of living in other places :)
It kind of is like office hours via chat.
For computer vision topics, StackOverflow is recently full of people who did a "deep learning expert in 4 hours" course and now need help with things that are covered in every textbook on the topic, like "what is disparity?".
Not everyone strives to be a teacher. Some of us also just want to work on cool stuff with like-minded people.
What works best entirely depends on what your goals, personal preferences and audience are.
I think this format is much better and more organized, so I highly recommend that open-source maintainers who would like to learn more about how their projects are used to give it a try.
1)Person X finds a way of doing something that works for them.
2)Person X writes an article either saying outright, or implying, that this is how it should be done for everyone
About the only universal statement I've every found useful is the one that says "Universal statements should always be treated with skepticism".
Also, this looks vaugely similar to the Pre Sales/Sales call as well.
Its a good idea. Schedule a session with an expert or someone who is working on the thing you're interested in / supporting.
I'd definitely link it to money so that the expert doesn't get overwhelmed / (ab)used by time wasters.
That direct two-way communication both unblocked adoption for users and was a source of feedback for the devs.
There are armies of retired, under employed, and even just people bored at work, ready to start making an impact.
What are your ideas?
More Open source projects For hardware and physical items
Involve people of all skills, marketing, PR, event planning, who knows!
A wonderful side effect of maintaining a channel like this has been that there is a tiny group of regulars now in the channel and we often discuss stuff other than open source projects too. Due to the nature of the projects, they attract like-minded people into the channel, so a lot of time is spent in discussing mathematics and computer science literature, and Lisp, Emacs, etc. What started as a support channel has gradually evolved into a tiny book club for mathematics and computer science!
I'm an old, and any sense of obligation in the FOSS space, even self-imposed or projected, is bewildering to me.
If I wasn't then I wouldn't be doing this (or suggesting it to others).
https://calendar.google.com/calendar/embed?src=redhatstreami...
"the challenges of taking an open source project and turning it into a full-time job, earning a salary good enough to avoid the siren call of working for a FAANG company"
and
"this as an opportunity for earning money against an open source project, and I think it could complement office hours nicely: 25 minutes on a Friday free on a first-come, first-served basis could then up-sell to a 1.5 hours paid consulting session, which could then lead to larger consulting contracts"
So, is the article more about clicks leading to revenue, and less about what the headline appears to say, like so many others?
Not all open source maintainers are this lucky (or reached such a great level of success such as Simon in this case).
Most open source maintainers have real product obligations inside their companies and either have little company time for this or have to do it entirely in their own time. Scheduling office hours seems like a luxury in these situations.
"I’d like to encourage more open source project maintainers to consider doing something similar."
If you consider it and decide that it's not for you that's absolutely fine!
On the open source projects I supervise which have a fairly big reach, it's simply impossible to do that, especially since I work on it a few times at night each week.
Having office hours would mean dedicate even more time to them, which I can't.
It would mean speaking in a common language, probably English. Writing in English is one thing - talking in English is another. It's super tough for some foreigners (including myself).
It would also mean much more organization. Calendar invites, Zoom or whatever tools, etc...
https://sidekiq.org/support.html
Office hours are great because they remove the admin overhead of scheduling individual appointments.
But get right out of here with that “should” nonsense. OSS maintainers are already donating time and effort for the common good. You’d have to be a complete jerkwad to insist they need to do more.
Alternatively: Tech Bros go ahead!
Generally, communication with your users is a good idea, because it gives you insights in how your tools are being used, and gives you a chance to - by asking the right questions - improve your code, and your relationship with the community.
It is about building and applying soft skills.
Your full-time-working, full-time learning, open-source-contributing mother of several children may choose not to do so. Or maybe she can cut some time from the full-time learning and train her people skills, and make her open source product better. Because in the end, a well-run, useful OSS portfolio helps building reputation that is more useful in a hiring situation than deep knowledge about the shortfalls of the Dijkstra algorithm for edge cases.
We’ve been working with the Nuxt.js team and iterating on the product for over a year. It has become a full featured live chat, and invoicing system, with a contact widget for onboarding clients.
Feel free to email me at dylan@otechie.com if you’re interested