People who want office hours should pay open source projects to do so
I think the opposite is true as well. Having office hours will lead to more companies using and paying for support contracts.
Open source projects should run office hours
41–50 of 279 posts
Re: Open source projects should run office hours
#42I 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 c…
I thought "office hours" is a common term in universities?
It is where I went at least
Re: Open source projects should run office hours
#43Agreed. 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.
Re: Open source projects should run office hours
#44Isn'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 fulltim…
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 that it's a really valuable suggestion.
I don't understand what you're saying. How is time spent gathering feedback from users not time spent working on the project?
Re: Open source projects should run office hours
#45Earlier quoted context omitted.
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 fe…
>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 tha…
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.
Re: Open source projects should run office hours
#46The Airbyte guys do this but honestly I find more utility in the fact that they have an open slack that they're responsive on.
Re: Open source projects should run office hours
#47Isn'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 fulltim…
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!
Re: Open source projects should run office hours
#48Anyone can run office hours for any of their open source projects they want - that sounds great! 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.
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.
Re: Open source projects should run office hours
#49Earlier quoted context omitted.
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 fe…
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.
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).
Re: Open source projects should run office hours
#50Earlier quoted context omitted.
I think the 'should' is targeted at developers who want their projects to grow (which is not all open-source developers).
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 fe…
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.