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'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
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.
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.
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.
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.
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.
>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.
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.
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 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.
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.
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.
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.
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.
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!
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.
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
Hey! I started a platform called Otechie to help open source projects build consulting businesses. I believe this is the perfect way for open source projects to monetize, because they are the worlds experts in something lots of businesses want help with.
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
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
278 comments
[ 2.2 ms ] story [ 289 ms ] threadI love this.
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.
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.
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.
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.
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.
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.
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 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 :)
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.
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.
In exchange for that I get extremely high bandwidth feedback from real users of my software!
Are you certain? I'd think most open source development is done by paid developers, on company time.
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
[1] https://github.com/typesense/typesense
I need to find some place/way to use this. It looks interesting.
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
Now I'm wondering if I should make it available for the lower tiers as well.
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).
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.
The tautology that if you want feedback then you want feedback is true. The rest is bullshit.
Easy, request they have a quick 5min feedback chat with you and you'll bump their issue on the priority list.
[1] https://docs.darklang.com/contributing/getting-started
https://sidekiq.org/support.html
[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.