10 ms·

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

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.

coliveira 6y ago
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.
- akavel 6y ago
  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.
  - Aeolun 6y ago
    I have no expectations of other open-source maintainers that I don’t have of myself.
  - KDJohnBrown 6y ago
    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 powerful.
    - eeZah7Ux 6y ago
      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).
  - imtringued 6y ago
    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.
watwut 6y ago
I agree with you, but the article is not about that.
- matkoniecz 6y ago
  I referred specifically to the title in my comment.
  - danaliv 6y ago
    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.
nxpnsv 6y ago
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.
- matkoniecz 6y ago
  I referred specifically to the title in my comment. It is part of things personally irritating to me, and something what is biggest threat to small open source projects that I like. People are mistaken in thinking that having an open source project implies any obligation beyond lack of malice. And people tired by dealing with that are one of top reason why open source projects disappear or are never created.
  - whizzter 6y ago
    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)
    - deleted 6y ago
      [deleted]
    - GordonS 6y ago
      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.
      - RBerenguel 6y ago
deleted 6y ago
[deleted]
corobo 6y ago
So don't do it? If it doesn't work for you, remove yourself from the target audience of this post lmao Classic SHOULD vs MUST. This comment thread is being upvoted because.. wait we're not supposed to suggest someone didn't read the article here are we :)
mcherm 6y ago
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".
- 1f60c 6y ago
  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).
  - fuzzfactor 6y ago
    >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.
teh_klev 6y ago
Should doesn't mean must, the title is ok with me. See also :) https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/rfc2119
- capableweb 6y ago
  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.
  - teh_klev 6y ago
    This was meant as humour, hence the explicit smiley face on the end.
- arkitaip 6y ago
  I can't imagine a more HN thing than someone referencing a technical specification to define the word 'should'.
  - teh_klev 6y ago
    It was an open goal, how could I not? :)
simonw 6y ago
The curse of snappy titles. A clearer version of my message is in the third paragraph: "I’d like to encourage more open source project maintainers to consider doing something similar."
- matkoniecz 6y ago
  I 100% agree with that version!
- taberiand 6y ago
  I just mentally prefix titles like this with [The author's opinion is that...]
mysterydip 6y ago
Depending on license, aren't you obligated to provide a repo if you're using the code (ie GPL)? Or do I misunderstand it?
- capableweb 6y ago
  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). Short version of your obligations if using GPL as a license: https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) https://tldrlegal.com/license/gnu-general-public-license-v3-...
  - bachmeier 6y ago
    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.
  - account42 6y ago
    > btw, GPL is considered a "free" license Yes. > not a "open source" one It is also an open source license.
- bachmeier 6y ago
  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.
- layer8 6y ago
  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.
simonw 6y ago
Headline changed to "Open source projects: consider running office hours"
- matkoniecz 6y ago
  Thanks! Sadly I can not edit my comment, in this case it would be useful :(
- lolsal 6y ago
  Hey you responded to my comments elsewhere, but I just saw this - this definitely changes the tone for me, thank you!
deleted 6y ago
[deleted]
C4stor 6y ago
What happened to the HN rule of "interpret everything with the most positive interpretation possible", when this is the top voted comment ? It seems pretty obvious that the author doesn't intend to coerce anyone into doing anything.
- throwawinsider 6y ago
  It seems pretty obvious to me that should means should. Pro tip: if you don't mean should, don't write should.
  - Supermancho 6y ago
    Another pro tip: Never use the word "should". Avoiding reasoning about the nature of your beliefs (and why others might be subject to those beliefs) is a weakness in thinking. "Should" is also the easiest way to create a clickbait headline to argue about because there are so many individual interpretations and following justifications of "should".
    - ghaff 6y ago
      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."
  - carols10cents 6y ago
    Pro tip: the best RFC is 2119 https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/rfc2119
    - account42 6y ago
      Don't you mean "Pro tip: you SHOULD read RFC 2119"
- eeZah7Ux 6y ago
  The rules are rarely followed. So many times I get bunches of silent downvotes just because...
that_guy_iain 6y ago
> 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. /rant
lhorie 6y ago
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. Personally I think this a really clever idea
- armoredkitten 6y ago
  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.
kjrose 6y ago
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.
- simonw 6y ago
  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.
  - kjrose 6y ago
    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.
tikiman163 6y ago
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.

coliveira 6y ago

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.

akavel 6y ago
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.
- Aeolun 6y ago
  I have no expectations of other open-source maintainers that I don’t have of myself.
- KDJohnBrown 6y ago
  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 powerful.
  - eeZah7Ux 6y ago
    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).
- imtringued 6y ago
  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.

watwut 6y ago

I agree with you, but the article is not about that.

matkoniecz 6y ago
I referred specifically to the title in my comment.
- danaliv 6y ago
  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.

nxpnsv 6y ago

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.

matkoniecz 6y ago
I referred specifically to the title in my comment. It is part of things personally irritating to me, and something what is biggest threat to small open source projects that I like. People are mistaken in thinking that having an open source project implies any obligation beyond lack of malice. And people tired by dealing with that are one of top reason why open source projects disappear or are never created.
- whizzter 6y ago
  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)
  - deleted 6y ago
    [deleted]
  - GordonS 6y ago
    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.
    - RBerenguel 6y ago

deleted 6y ago

[deleted]

corobo 6y ago

So don't do it? If it doesn't work for you, remove yourself from the target audience of this post lmao Classic SHOULD vs MUST. This comment thread is being upvoted because.. wait we're not supposed to suggest someone didn't read the article here are we :)

mcherm 6y ago

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".

1f60c 6y ago
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).
- fuzzfactor 6y ago
  >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.

teh_klev 6y ago

Should doesn't mean must, the title is ok with me. See also :) https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/rfc2119

capableweb 6y ago
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.
- teh_klev 6y ago
  This was meant as humour, hence the explicit smiley face on the end.
arkitaip 6y ago
I can't imagine a more HN thing than someone referencing a technical specification to define the word 'should'.
- teh_klev 6y ago
  It was an open goal, how could I not? :)

simonw 6y ago

The curse of snappy titles. A clearer version of my message is in the third paragraph: "I’d like to encourage more open source project maintainers to consider doing something similar."

matkoniecz 6y ago
I 100% agree with that version!
taberiand 6y ago
I just mentally prefix titles like this with [The author's opinion is that...]

mysterydip 6y ago

Depending on license, aren't you obligated to provide a repo if you're using the code (ie GPL)? Or do I misunderstand it?

capableweb 6y ago
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). Short version of your obligations if using GPL as a license: https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) https://tldrlegal.com/license/gnu-general-public-license-v3-...
- bachmeier 6y ago
  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.
- account42 6y ago
  > btw, GPL is considered a "free" license Yes. > not a "open source" one It is also an open source license.
bachmeier 6y ago
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.
layer8 6y ago
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.

simonw 6y ago

Headline changed to "Open source projects: consider running office hours"

matkoniecz 6y ago
Thanks! Sadly I can not edit my comment, in this case it would be useful :(
lolsal 6y ago
Hey you responded to my comments elsewhere, but I just saw this - this definitely changes the tone for me, thank you!

deleted 6y ago

[deleted]

C4stor 6y ago

What happened to the HN rule of "interpret everything with the most positive interpretation possible", when this is the top voted comment ? It seems pretty obvious that the author doesn't intend to coerce anyone into doing anything.

throwawinsider 6y ago
It seems pretty obvious to me that should means should. Pro tip: if you don't mean should, don't write should.
- Supermancho 6y ago
  Another pro tip: Never use the word "should". Avoiding reasoning about the nature of your beliefs (and why others might be subject to those beliefs) is a weakness in thinking. "Should" is also the easiest way to create a clickbait headline to argue about because there are so many individual interpretations and following justifications of "should".
  - ghaff 6y ago
    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."
- carols10cents 6y ago
  Pro tip: the best RFC is 2119 https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/rfc2119
  - account42 6y ago
    Don't you mean "Pro tip: you SHOULD read RFC 2119"
eeZah7Ux 6y ago
The rules are rarely followed. So many times I get bunches of silent downvotes just because...

that_guy_iain 6y ago

> 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. /rant

lhorie 6y ago

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. Personally I think this a really clever idea

armoredkitten 6y ago
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.

kjrose 6y ago

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.

simonw 6y ago
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.
- kjrose 6y ago
  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.

tikiman163 6y ago

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.