I have deep aversion to "Open source projects should run office hours" title.
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 is overruled by the "law of the topmost comment" - the top comment is very likely a negative take on some subpart of the topic at hand, sometimes unrelated to the actual article, worded in the strongest way possible.
Everything about your comment is just wrong, so wrong.
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.
I thought that rule was for interpreting comments to keep civil discussion. Identifying possible interpretations of what is in an article and the biases it may either imply, be sourced from, or create in others seems a worthwhile topic to discuss about an article, though care must be taken to distinguish from 'could imply' and 'does imply'.
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.
Such office hours could have a price. Given how much consultants charge it wouldn't be unreasonable to charge $500/hour (being a maintainer comes with deep knowledge).
The article mentions that - he thinks of the 25 minute sessions as more about learning how people use the software, and increasing his ability to make something cool.
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 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?
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...).
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".
Depending upon the context, "should" can run the gamut of "here's an idea that you might want to consider" to "you have a serious moral failing if you don't do things this way."
I don't think this is about obligations. I feel the developer had a hugely positive experience in inviting interested strangers for 20 minute chats and wanted to spread the positivity. Seems like a nice person, with a nice project, and clearly some extra time available.
The title is kinda unclear for someone non-English/US, for me office hours only means the actual hours when things are worked on (rather than any kind of availability time).
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)
I am a native speaker (well, Scottish, so some may disagree ;), and I didn't get the title either. Maybe it's an American thing, by "office hours" to me means 9-5, local time - you know, the kind of hours that people typically work in an office.
To me (non-native, Spain), I read "office hours" as the time when I was a teacher in university: you have a set period of time where you are marked as available in your office for student consultation. I'm pretty sure that's what "office hours" is supposed to mean, although in Spanish and Catalan the word used would literally translate as "consultation hours" (horas/hores de consulta).
The term "office hours" in American English can mean either of these concepts, but in the current context it clearly means the one you suggest ("horas de consulta").
In American English it can mean that too. The meaning of "certain hours where you work" and "certain hours where you have an 'open office'" overlap enough to be confusing, yes.
When you run your own organization you can set your own office hours.
> 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.
No, this is actually not what it means. "Office hours" has two distinct meanings: one is the hours you are in the office. That is not what is meant here. The other meaning, which is what is meant here, is specifically designated times when experts make themselves available for random questions about the thing they're an expert on.
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.
The difference in usage is not localized English: it's cultural student/academic vs. employed.
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.
To clarify the distinction is both academic AND language/culture. The concept of professorial office hours, and calling it "office hours" is not universal to all of academia, as people there speak different languages, and use then different words for things. Even if they might also use English, it doesn't mean they would call it that.
I think the authors explanation with the german word "Sprechstunde" is really great. There is a clear distinction between "Arbeitszeit" which is the working time and the "Sprechstunde" which is the time someone is available to talk to.
I'm not a native english speaker either, but typically, in American usage, "office hours" refers to published, allocated hours for someone, such as a professor at a university, to allow walk-ins where (s)he can answer students' questions 1-on-1 above and beyond the classroom hours. I guess this expands to other settings too.
"could" is true but irrelevant and therefore implies subtext. I don't think "could" would be much better, it ought to just be re-phrased as a suggestion in the first place.
I understand your point, and I also think it's weird how people feel entitled to the free time of others. Still - here the choice of title has gotten in the way of what the author wanted to convey, and I feel the story deserves a read beyond the title.
I saw the title and thought to myself, "No one has the right to tell open source volunteers how to spend their time! The only way an article with that title is acceptable is if it's talking about benefits to the DEVELOPER, not the user."
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".
For me (a non-native English speaker) the title was confusing for a related, but entirely different reason: it's referring to the kind of "office hours" a professor might have, not saying that you "should" work on your open source project during office hours (i.e. from Monday through Friday from 9 AM till 5 PM).
>saying that you "should" work on your open source project during office hours (i.e. from Monday through Friday from 9 AM till 5 PM).
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.
The IETF is not the ones deciding how the English language works, especially not outside of their own specifications ;)
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.
The point of this article was to address the fact that open source project rarely get good user feedback. Developers wouldn't necessarily be the person offering time to talk with users, it would be the project owner. I know open-source projects don't have traditional roles like a product owner or scrum master, but there's still somebody prioritizing a list of features that have been requested. Offering to meet with real users provides valuable insight into what they actually need. This can help with prioritizating features, and even help with making decisions about whether to approve a random PR you get for a feature you didn't put into the backlog based on whether it might make future real needs harder to achieve.
The submission title appears to be editorialized. Original title is "Open source projects: consider running 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.
Actually, the submission title is referencing the original title of the article, but the author edited it and left a note at the bottom:
>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.
It's a clickbait title. That being said the real idea is the freemium consulting concept. Basically open source Devs give free consulting for a short time and then upselling to full on consulting for extended periods at full price.
In theory it could be a way to fund open source dev.
It's actually not so much about free consulting where I help them, it's more the other way round: they help me figure out how to improve the software by showing me what they've built or talking about what they want to achieve.
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.
Oh, I get the idea that the market research has a benefit as well. However, a major issue with Open Source development is funding it so that it becomes self-sustainable, especially for situations where the code requires significant work to keep it up to date.
I feel the gem in this article is the freemium idea for consulting on open source development.
Under GPL-like licenses you are obligated to provide source code if you provide a binary. If you don’t distribute anything, e.g. you only use something privately, then there are effectively no obligations. Of course, if you don’t provide source code for your project (whether legitimately or not), then by definition your project is not open source in the first place.
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.
> Under GPL-like licenses you are obligated to provide source code if you provide a binary
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.
If you're redistributing someone else's GPL code in binary form, you also have to redistribute it in source form. A software license doesn't impose any restrictions on the person writing the code. It provides the conditions under which others can use it.
There are a few MUSTs if using GPL, yes (btw, GPL is considered a "free" license, not a "open source" one), but providing a repository is not one of them. Although you do need to provide the source (in any means you want, as long as it's accessible, making a repository is one of the ways, bundling a zip file would be another).
Those are obligations if you're redistributing someone else's GPL code. You'd have to sue yourself to ensure compliance with your own license if it applied to you.
Yes, we're aware. The criticism is that you didn't engage with the substance of the actual idea, and instead spawned a ten-page thread about something the article doesn't say.
> 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 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.
You're completely right. However, I notice a change in behavior in developers during the last decade. They view open source as an extension of their duties as software developers, i.e., something that they have to do. Following this point of view, they consider that working on a project brings commitments as if they were in a paid job, and started projecting this belief on others. I think this is very disturbing.
You may have gotten this in reverse direction: it's rather that users of open-source software often desire support, and sometimes speak about it, and developers then tend to have hard time managing psychological boundaries with regards to answering that desire/expectation. Which is generally a nontrivial thing between people in any relation.
Yes, the idea behind the office hours is that you can point people at your calendar. If the calendar is full then that's how it is. Maybe the team has to grow to accommodate the increased demand but the maintainer certainly won't spend an extra hour working on the project beyond the time he allocated.
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.
Interesting historical note, this is how Chef was born.
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 probably driven by many companies astroturfing FOSS.
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).
I think a lot of the comments are concluding from the title that open source maintainers should be working on the projects during office hours.
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’ve come across it in various largely-Americentric writing and figured out the concept, but yeah, it’s not something I’ve seen practised in Australia.
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.
In my experience, US professors generally were open door as well but it was about catching them being in their office. They could be lecturing, faculty meeting, lunch, etc, etc, etc.
Office Hours is a way of saying I will DEFINITELY be in my office at my desk during this block of time.
It is a common term in different areas, however not everybody here comes from an English speaking country and is knowing all English terms. For many English is second or third language.
In this case, you need to be American to make sense of this. And possibly you need to have been to a US university. Took me years of seeing people put a confusing number 101 on the end of guides on blogs or whatever before I realised that meant introduction to Americans.
Do any of the comments actually make that conclusion? The other comment you replied to is the only one I saw that even comes close, but it mentions "if you can offer office hours..." so the poster clearly knew the "office hours" idiom.
I came into the comments section to see what this article is all about and whether I want to read it, thinking it would be about working on open source projects only 9 am to 5 pm. So this comment helped me a lot, and I'm voting it up so that it may stay on top.
Oh, don't get me wrong, I definitely think it's helpful to explain the idiom for those not familiar. I just found the description "a lot of the comments..." rather weird when I didn't see any.
ok, gonna make a meta-comment here: Can you point to such comments? Somehow I keep seeing people say things like this despite there not being any (or only 1-2) comments actually doing the thing they say "a lot of" the comments are doing, and I don't understand it.
Office hours are work. Soliciting feedback is work. Having a chat about your project is work. Rhetorical jujitsu to make that work sound like not work is at best a failing of empathy.
The tautology that if you want feedback then you want feedback is true. The rest is bullshit.
I've had massive success with this in ML. My twitter DMs have become almost-daily office hour sessions with people trying to solve hard ML problems. The last fellow was so happy he venmo'd me $250 after I merely asked for "pay whatever you thought that was worth."
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.
It's kind of neat observing the same economics that drive Instagram influencers also drive sharing logical thinking. I wonder if both sides of the human brain behave the same way? (organic v. ogic). Actually it's far more likely that social effects are the cause, and social effects benefit both organic runaway trains as well as logical runaway trains.
On the other hand, $250 was probably way too little money. I question the wisdom of helping people who are professional be-at-the-right-place-at-the-right-timers. That includes people working for giant companies messaging open source maintainers, or any number of total inequities.
you're putting a lot of weight on someone having the right followers or someone casually reading some rando.com website. comparing that roll of the dice big bang level of random vs having direct contact with someone that uses code you created and can vouch for you seems skewed in the wrong direction to me.
I helped a fella figure out how to imbue their GPT model with emotional awareness. That was one of the cooler ones, and we solved it in about an hour or so.
The actual technique will take a month or so to execute, but the core idea is pretty much guaranteed to work.
Interesting! Are you able to share what you came up with? It seems like at minimum you could verify that the sentiment analysis for your generated text matches that of the input prompt.
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.
I might be able to, but I'll have to ask. Want to DM me on twitter, so that I can share it with you (if permission is given) without broadcasting it to the world? https://twitter.com/theshawwn
Isn't this kind of a paradox? Most open source maintainers work in their free time on those projects, and have an additional fulltime job to cover the bills.
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 my case I'm still very much trying to encourage people to use my project. The time investment for office hours isn't too high - I actually dropped it down to three sessions every Friday for a while due to other commitments, so it's only an hour and a half a week.
In exchange for that I get extremely high bandwidth feedback from real users of my software!
Looks like you're drawing conclusions from the title, which I also did!
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 you're missing the distinction between "office hours" (what most people would read as 9-5 Monday through Friday) and "Office Hours", the term Simon is using to describe the 4-5 hours a week that he specifically allocates to having discussions with his users. Which is completely understandable given that there's not actually a consistent capitalisation difference.
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.
Ah, I see what you mean. People generally wouldn't say "run office hours" to refer to the first sense. That might be "work office hours" or "standard office hours" or "keep office hours" perhaps.
The article describes a practice for gathering feedback for your project: announce a set time when people can get on a call with you for a few minutes and discuss your project. The author calls this "office hours".
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.
I assumed this was written from the perspective of someone trying to turn an open source project into a paying gig by attracting sponsors, patrons, etc.
Since about half of this thread is (reasonably) taking offense at the implication from the headline that this is yet another demand for free labor from open source maintainers, I'd like to emphasize this sentence:
"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 re-titled it "Open source projects: consider running office hours" - if a bunch of different people all misinterpret something the same way that implies poor communication on my part.
No it doesn't imply that. Your article is crystal clear, and makes a valid point based on your personal experience. So, thanks for writing it, and don't bother too much for internet points !
I think the problem here is that a lot of people (myself included) will understand the term "office hours" as being the typical time window that people work in the office - i.e. 8am to 5pm.
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 considered that point of confusion too, but I decided I'm OK with people who are unfamiliar with the term "office hours" needing to click through and read the article. I picked "consider running office hours" because hopefully the word "running" there is slightly less likely to imply "consider only working 9-5pm".
OSS devs rely on donations, but office hours would be a great paid service. The demand for OSS is so high, depending on the centrality of your library, you could easily charge $10-$100 an hour for this.
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!
It seems like the bulk of OSS developers I know do not get paid, but are obsessed with a particular problem domain (or have essentially merged with their tool and become a finely tuned cyborg).
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).
I've been thinking about doing office hours recently and this is just the motivation I needed to set it up! So thank you OP.
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
Services with notifications like GitHub should allow you to delay notifications until your indicated availability. Ignoring them isn't good enough and some people have them sent to their personal email.
This is a great idea. It's time-bound, so the maintainer doesn't feel set-upon, since they can change the hours whenever. It's also a (reasonably) guaranteed opportunity to talk directly to the maintainer of something you care about, if you're on the other side.
I used to work on a reasonably sized open source project (10k+ stars on GitHub). We held approximately monthly office hours on Zoom. Very few people ever came to them. I think the average was less than one person.
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.
Maybe the big difference here is getting people to book slots?
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.
In the educational setting, this is a massive effect. If I offer students feedback slots they can book, generally a majority will book a slot, and around 90% of those will turn up. If I just offer times they can drop in for feedback, I get maybe 5% dropping in.
(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 :-)
The Knative Project holds "Hacky Hours" every week on Fridays, 1-3pm Pacific Time[0]. It's a great opportunity for people to drop-in and ask questions, and for folks to show off what they've been working on.
[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.
To riff on this I think this weird expectation of projects to "grow" is a side effect of the increasing corporate influence on F/OSS.
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.
>To riff on this I think this weird expectation of projects to "grow" is a side effect of the increasing corporate influence on F/OSS.
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.
Right, but human propensity to seek status hasn't changed, and if anything it's been amplified by corporate interests more than simply just the internet's ability to connect.
> 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.
Open source developers presumably tend to work on projects that they genuinely like and are passionate about. Aiming to help as many people as possible in a subject you're passionate about seems extremely natural to me.
Agreed, this is something that is incredibly obvious when there's no money involved. It's naive, wasteful in a sense (your time could theoretically be used for other things), but that's the open source that everyone respects/admires.
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 was told that internally at Redhat if you’re assigned to a project and the project becomes unsupported by the company, you have a certain amount of time to be picked up by another team, after which, if you aren’t, you are let go.
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.
This is more or less also how IBM operates. I know someone who had to interview for other teams at IBM because their other IBM project ended. After a while of trying to navigate the politics of it all they just gave up on IBM completely.
Sorry maybe I don't have my moral sensors tuned properly today but would you mind explaining what makes you feel uncomfortable about it?
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).
> 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?
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.
My goal with Datasette is to grow a plugin ecosystem that provides a wide range of extra feature which I didn't have to build myself - so in my case I have a strong incentive to attract more users for non-vanity reasons.
This riff was much less about Datasette and more about other projects (let's say the latest CNCF incubation stage project). Not that I'm important but I distinguish small-ish (or even projects that have grown larger) trying to publicize to attract more talent, but that smells different than large professional-looking efforts for open-core software or shareware which I often also see. Someone putting a "hey we're 1000 strong, come join us and contribute" at FOSSDEM is different than a company with some light VC funding talking about Github stars and "engagement" at Kubecon.
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 understand that, but a person new to the development world might see this as something expected for anyone starting an open source project.
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.
At my previous job, I used to run "office hours" originally as a way to onboard new engineers. They later turned into discussions on technical topics when someone needed it.
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.
You're talking about a 'job' and 'onboarding' engineers - that's quiet a departure from what I think most people imagine when they imagine an open source project.
Office hours for an office-like job sound totally reasonable.
Yeah, with hindsight I should have picked a different word.
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.
My mistake - I meant to reply to the discussion about people misunderstanding the expression "office hours" and attached it to the wrong subthread. This is not related to your point about "should" at all.
FWIW, we've got a #redux channel in the Reactiflux Discord where I and a couple other Redux maintainers hang out and answer an ongoing stream of questions. Not sure having specific "office hours" slots would work well for us, but we're happy to answer questions whenever we're around.
The very short consulting can be pretty intense. People come fast and furious and want answers. They sometimes are folks who really badly need a larger consulting or training engagement from a specialist, but can't afford it. So they sometimes come hard, sometimes frantically, looking for miracle fixes.
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.
I can imagine there’s a “right” amount of this sort of thing. Like, if you work on a project doesn’t have much traction, it can be nice to have the people using it meeting up and talking about it. It can keep energy and motivation high. And hearing what people are working on (with demos) is a blast.
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.
My rule is anything you can do during the time it takes to eat lunch is free. If you need to bill something that small you need to rethink your business model.
Hi! If you're thinking of giving office hours for your project... I've been working on a site (http://booktime.xyz/) that's meant for this. It's like a calendly where you can manage different meeting types more easily, they can be paid or unpaid, and we keep your contact private. Feel free to email me at (david@booktime.xyz) too. We've been polishing it up, and I'm happy to take feedback.
Agreed. I recently added my calendly to Dark's contributor docs [1] for people who want to get started. No one has taken me up on it yet, but we'll see how it goes.
Interesting. Last week I finally managed to get Github and Stripe to approve the GH sponsors page for my project, and one of the "rewards" that I am offering to the higher tiers is access to a periodic "office-hours" conference call.
Now I'm wondering if I should make it available for the lower tiers as well.
For Jam (open source Clubhouse) we do a weekly “Jam Jam” which basically is an audio space that people can join (no video, no calendar slot negotiation, connecting with others who use the project).
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)
This but get it done in one. Get into live-streaming! The benefits of this office hours concept but with the potential for subscribers to the meeting-as-content.
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 :)
For those that don't understand (and I'm an Aussie so was a bit confused too), in US colleges, Professors have "office hours" which are pre-assigned times when they are available for 1-2-1 Q&A etc.
Many projects that I use already have IRC with permanent log, so you can just go in there and estimate the times when the regulars hang out from the logs. And then you join at that time, too.
I think having the explicit concept still has some value: a) "you can just go and ask" is a surprisingly large cultural barrier for many people (as are other conventions around developer channels), b) an explicitly set time will have higher success rate than guessing based on logs and c) it's also something the devs can structure and plan around. I.e. sure, I'll answer questions when I see them and have time, but steering people to ask when convenient to me also improves my experience maybe?
In my experience, you want a slightly inconvenient barrier, or else you'll be swamped with beginner's questions only partially related to your project.
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.
Sure, and that's a valid choice (although if IRC is the best filter, or just a convenient one, is arguable), but that's even more an argument that having an IRC channel is not quite the same as "having office hours by chat", especially if you don't want to have office hours. Maybe I just misinterpreted your initial comment, but to me it read like "we don't need office hours, our IRC channel does the same thing".
What works best entirely depends on what your goals, personal preferences and audience are.
It's called "support" and many companies pay for it to be provided by many of the major FOSS software producers; mileage with those services varying I'm sure. Making demands of indep producers? This "should" vocabulary I'm not a fan of. Maybe I'll write a blog post about all the things "others should do" and sure I will be heard? Sounds like there was plenty of extra time on the table for this author to make these office hrs to begin with
I had some good success running similar but not as organized sessions for our open-source project[1] in 2018-2019. There was no specific day of the week and calls were between 30-50 min.
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.
So, the future users/contributors can personally talk to the owner/maintainer of the OSS projects. This is good for both the parties. The owner/maintainer can get a huge set of idea/directions to take forward along with instilling some confidence in their users. This idea seems great to me.
Also, this looks vaugely similar to the Pre Sales/Sales call as well.
“Office hours” is something you hear in college. It’s a stated time of the week where the professor will be in their office and students can stop by to discuss course material, assignments, and ask questions in a one-on-one situation.
Something similar is one reason early Kubernetes was successful: many of the core people in the project were in an irc/slack channel available for anyone with questions.
That direct two-way communication both unblocked adoption for users and was a source of feedback for the devs.
I am a maintainer of Haystack, an open-source NLP search framework leveraging latest NLP models & information retrieval techniques. My Twitter DMs(same handle as here) are open if you're looking to revamp the search experience in your products.
I maintain a few small open source projects around publishing math on the web. I have a Freenode IRC channel and Matrix room bridged together where anyone is welcome to join anytime they need help. When I am relatively free, I also post a live web meeting URL to the channel where anyone can drop in or drop out anytime. So the Matrix/IRC channel along with occasional web meetings have been my version of office hours so far.
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!
My comment was incomplete earlier and I edited it to update it later but you had already posted your comment before my edit, so posting this comment to clarify that I do occasionally indeed provide my full attention. I sometimes post a web meeting link to the Matrix/IRC channel. Anyone is welcome to drop in to the web meeting or drop out at any time. However, I have not tried the approach of offering one-on-one meeting slots via calendar booking and relying on audio/video during the meetings and that is something I am eager to try out now.
Those office hours could be on the weekend if you wish, and nobody says that you have to have a longer time window to book than one or two hours a week. That's more than some lecturers.
Github / Gitlab / etc. are not free software universities where maintainers are professors enjoying their tenure. In my opinion, if you don't pay a maintainer for their time you are not entitled to it.
This is a great idea. Also any free slots could be opened up to general questions, perhaps via a Twitch or YouTube stream, so that the more general questions can be recorded for posterity and documentation.
Note: the author has changed the title. it is now "Open source projects should consider running office hours", precisely for the reasons highlighted here.
Red Hat holds a series of OpenShift office hour type segments as part of their OpenShift streaming calendar. The specific segments range from weekly to triweekly (every three weeks).
"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?
That section was mostly intended to pre-empt the expected complaints from people who would say "so you expect open source maintainers to give away even MORE of their time for free?"
It is unfair to propose this as a general idea when you're literally paid by a company to do whatever you want to do and work on your side projects on company time.
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.
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...
I've been running a "happy hour" at Friday 10am for 4-5 years now. Some weeks no one shows up. Some weeks 3-4 people will show up. The important thing is that I'm talking with users regularly so I get to help them and hear their pain points.
If you have the time to spare and the mental energy to talk to random strangers about their problems every Friday afternoon, good for you.
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.
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.