[HN Gopher] My boundaries as an open source developer
___________________________________________________________________
My boundaries as an open source developer
Author : cakeplease
Score : 157 points
Date : 2022-03-16 16:57 UTC (6 hours ago)
(HTM) web link (joeldenning.com)
(TXT) w3m dump (joeldenning.com)
| chmod600 wrote:
| If an author can publish code with a take-it-or-leave-it
| attitude, why can't people make requests with the same attitude?
| If the author is under no obligations at all, a request is no
| problem, right?
|
| Well, the problem is that it's not so absolute. Publishing
| something normally invites feedback and it's awkward to
| completely ignore it. Just like it's awkward when you report a
| bug and get silence.
|
| I'm not suggesting a real obligation, but there is... something?
| If there wasn't, then these requests would be treated like random
| mail to a famous person and just discarded.
| d4mi3n wrote:
| > Well, the problem is that it's not so absolute. Publishing
| something normally invites feedback and it's awkward to
| completely ignore it. Just like it's awkward when you report a
| bug and get silence.
|
| I think in a perfect world every request would be polite and
| reasonable, making what you say here objectively correct. Since
| this is not the case, this sadly becomes a subjective opinion.
|
| The fact of the matter is that when one deals with the general
| public in any form you get all forms of good and bad
| interactions.
|
| There's also an inherent asymmetry between the effort it takes
| for a small number of project maintainers to respond to a large
| number of project consumers.
|
| There's no clear-cut answer here, but I think it is reasonable
| to state that someone sending requests to a project should set
| their expectations to match whatever licensing or contractual
| agreements are present in the projects they interact with.
| GoToRO wrote:
| [deleted]
| woah wrote:
| I totally get where they are coming from but it does make it
| sound like unsupported software. After reading that, I would not
| use it without completely understanding the code as if I had
| written it myself (and maybe that's what you should do for every
| dependency anyway). I would probably look for another open source
| project to use instead.
|
| There seems to be a constant supply of people starting open
| source projects who _are_ willing to support them, and I 'm
| guessing that an alternative to this project will supersede it,
| resulting in people not bugging the author any more.
| zaSmilingIdiot wrote:
| > After reading that, I would not use it without completely
| understanding the code as if I had written it myself (and maybe
| that's what you should do for every dependency anyway).
|
| Isnt that the point? As in, it allows for the use of some
| (context-appropriate) open source upstream software to quickly
| flesh out some idea into an implementation, rather than
| expending time and effort writing certain code oneself (the
| user of the open source software). This doesn't absolve the
| user from the responsibility of eventually writing their own
| implementation, or alternatively, maintaining, that open source
| code/library/framework as a part of their overall codebase.
|
| And so I seriously miss the point of where the managing or
| maintaining of some open source code, to satisfy some other
| downstream project's requirements, is the responsibility of
| upstream... again, when downstream uses it they do so to
| benefit themselves by not having to write or maintain that
| piece of software, but that comes with risks along with the
| relevant benefits. As in, its a "dependency" (in the name) for
| a reason.
|
| I almost see it as bordering on a concept of entitlement to
| think that someone else (eg the original creator of some
| software) should spend time and effort fixing issues or adding
| functionality that benefits some user. Basically, one should
| always be considering that dependencies at the time of pulling
| them in are static and provided as is with no contract of
| maintenance, and that it might provide benefit currently but
| that there is a very real potential cost to using it in the
| future.
| layer8 wrote:
| > it does make it sound like unsupported software.
|
| They specifically welcome requests for professional support.
| jjav wrote:
| > it does make it sound like unsupported software
|
| Nearly all open source software is by definition unsupported
| (read the license).
|
| If you need support you can pay for it (and in the blog the
| author specifically states they are open to communications
| regarding paid consulting work).
| kccqzy wrote:
| > maybe that's what you should do for every dependency anyway
|
| Exactly. When your colleague wants to write new code in your
| repo you do a code review. When a stranger writes a large
| amount of code shouldn't you also do a code review?
| bjt wrote:
| Sometimes. Depends on the boundaries between your code and
| theirs.
|
| I write Go apps and deploy them in the cloud. I haven't done
| a code review of Linux, Docker, Kubernetes, or the Go
| standard library. When an independent person puts out a
| library that I'm going to depend on, yes I'll review its code
| first. When I'm building on something that's backed by a big
| company (Google) or solid foundation (the PSF) then rather
| than reviewing the code, I'm more likely just to review the
| interface and docs. There's a continuum of possibilities in
| between. Different people may rationally draw the line where
| they'll do code reviews at different places on that
| continuum.
| FooBarWidget wrote:
| > but it does make it sound like unsupported software
|
| Pretty much every open source license contains a section along
| the lines of "there is absolutely no warranty". Older projects
| make this crystal clear in their readme. Newer, hipper projects
| don't, but that's only because they don't state it as
| explicitly.
|
| Open source software _is_ unsupported software unless you paid
| for a support contract. If you still get support despite not
| having paid for such a contract, then that support is an
| incidental gift that can go away at any time for any reason.
| saagarjha wrote:
| There's a difference between "please don't ask for support"
| and "I'm happy to support you even though legally you can't
| force me to support this".
| [deleted]
| henning wrote:
| > I totally get where they are coming from but it does make it
| sound like unsupported software
|
| That's exactly what it is, exactly how it says in the license:
|
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
| EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
| OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
| NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
| HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
| WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
| FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
| OTHER DEALINGS IN THE SOFTWARE.
| [deleted]
| wildmanx wrote:
| So much this. I'm glad he put this out there. I'll start linking
| to it too.
|
| There seems to be a common misconception about open source. When
| I release software as open source, it does not mean I work for
| you for free, need to provide you with anything, even need to be
| nice to you. I may. Or I may not.
|
| When I release software under an open source license, then we
| have a very specific deal. You are entitled to do certain things
| with the software, for example use it free of charge, or change
| it, or redistribute it, and I'm entitled to certain things in
| return, for example you keep attribution, you publish changes
| that you made under the same license, etc. Nothing more, nothing
| less. I could be an individual that hacked something in their
| free time, or I'm a multi-national mega-corp. Does not matter. It
| just means we have a deal.
|
| It's nice if a community emerges, and if I feel like it, I may
| participate in it. And accept pull requests or help with
| troubleshooting or implement new features. But I don't have to
| and I don't have to feel any obligation whatsoever. Anybody who
| thinks otherwise has misunderstood the concept or is maliciously
| misusing it.
|
| That's it.
|
| This is misunderstood not just by users, but even by creators
| themselves. They feel pressure, they feel bad if they don't
| respond in time, or implement new requested features, or accept
| pull requests. They shouldn't. Open source just means I published
| it once with a very specific deal. I may continue to do so if it
| makes sense to me, but I can also just stop doing so. I implement
| features when I have a reason for it, for example I like to have
| them in the software so I can use them myself, or maybe because
| I'm a corp that sees a business need. But implementing them for
| free just because somebody asked for it, that's just asking for
| trouble. If you do that regularly, and not mostly because you
| think it's fun, but because you want to "support the community"
| or whatnot, you are taking steps towards burnout, and ultimately
| are not just hurting yourself but even the larger community,
| because you are fostering the expectation that that's what open
| source devs should do. No, they shouldn't. That's not what open
| source is about.
|
| It's about a specific deal. Nothing more, nothing less.
| lmilcin wrote:
| I only have one rule: I only contact an open source developer if
| I believe resolving the problem would make the product better
| unless I am willing to offer them reasonable money to do it.
| einpoklum wrote:
| Doesn't (almost) every bug report/feature request meet this
| criterion?
| not2b wrote:
| This post is about when it is or isn't appropriate to
| directly contact the principal developer instead of using the
| established Slack or Github flows.
| lawn wrote:
| A counterpoint:
|
| You may view this feature as making the product better, but it
| might not fit the vision of the owner/developer and to them it
| will only generate a maintenance burden and bloat.
| TheCoelacanth wrote:
| You can't know that before you contact them, though.
| qbasic_forever wrote:
| The preference of the developer doesn't feed into your decision
| to contact them? What if the repo readme says "this is provided
| as-is, I don't offer support"?
| JJMcJ wrote:
| An XKCD that's right on target: https://xkcd.com/2347/
| gsliepen wrote:
| Dealing with users/contributors in open source indeed has its
| issues due to the low barrier and global nature, meaning you can
| receive both high and low quality comments/patches/etc, and
| sometimes the language barrier makes a good quality interaction
| look bad. In order not to drain your energy dealing with them,
| you have learn how to deal with them efficiently. What works for
| me is:
|
| - Always respond to the initial question/comment/PR. Not
| necessarily immediately. But it lets people know you have seen it
| and they are not being ignored. If they DM but you rather have
| them use another way of communicating, just point that out.
|
| - Give people the benefit of the doubt. Some people just don't
| know how to ask a good question or how to report an issue in a
| constructive way, so just respond with a remark that nudges them
| in the right direction, possibly have some document ready
| describing how people should ask questions (for example, like
| https://stackoverflow.com/help/how-to-ask).
|
| - Don't continue fruitless discussions. I don't repeat things I
| said earlier, unless there is something to clarify. If someone
| disagrees with me and I don't see the merit in their points, then
| so be it. At some point you just have to ignore messages, and
| don't feel bad about doing that. If someone DMs and you said to
| create a ticket instead, and they DM again saying things like
| "but it's just this small thing" or "but I just told you", I'll
| just ignore that, and if they really care about the issue they'll
| eventually figure it out.
|
| - When it comes to low quality pull requests, tell the author how
| to improve them. Ideally, I should be able to merge PRs without
| any changes necessary on my part. This will both lower the amount
| of work I have to do, as well as educate the author so they will
| be more productive in the future.
|
| - I try not to be too fussy about _how_ people want to
| contribute. I 'll just as happy to accept a patch sent via email
| as a PR. And sometimes it's just less work to copy&paste a DM
| into a ticket instead of educating the user.
| ikiris wrote:
| gurchik wrote:
| I don't think this is a fair characterization of the article.
| It's really not too much to ask to ask a user to go through
| official channels like a bug tracker or a mailing list instead
| of messaging the author directly. And I don't think it's right
| to accuse someone of hating their users for creating those
| channels. The only reason an author would make those channels
| is if they believe it would increase the chances of everyone
| receiving the best help.
|
| It's usually harder to find an authors direct contact
| information than the official channels. If the user has a
| legitimate bug report or issue, being told they accidentally
| found the wrong contact information wouldn't bother many.
| However if the user is going through backdoor channels
| specifically to get special treatment then that isn't fair to
| others.
| afarrell wrote:
| This isn't hate. This is indifference and conservation of
| energy.
| thenerdhead wrote:
| I think the missing aspect is that the platforms put this stuff
| in front of your face and human curiosity will have your
| attention directed at it anyway. You will actively be thinking
| about that troll who opened up an issue or someone in your
| Twitter DMs asking for help.
|
| Although I respect the author's boundaries, that is sadly just
| part of the job of putting your work on the internet. This does
| not just stop at open source, if you put anything out for the
| world to consume, do know that this is what you're signing up for
| whether you like it or not. People will "find a way" to contact
| you and won't read your boundaries or even know about them before
| they do.
|
| I keep an autoresponder in a notes file that I copy and paste
| regularly as it's a full time job to keep up with the requests.
| GoToRO wrote:
| henryfjordan wrote:
| The license very clearly tells you that you should not assume
| that the software is "production ready" and that if you do,
| that's on you.
|
| > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
| KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
| WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
| ...
| GoToRO wrote:
| You quote doesn't mean what you think it means. It just means
| "we will hide the real state of our software because we can,
| so you can choose to loose valuable time evaluating it now or
| else more time fixing it later. We could tell exactly how
| production ready it is, but we choose not to."
| henryfjordan wrote:
| The code is open-source, nobody is hiding the "real state
| of the software".
|
| "Production-ready" means different things to different
| people. For many, "production-ready" means "we have a
| support contract with the software vendor". In that case,
| the project would never be usable in production. To others
| with higher risk tolerance, a 1.0.0 release is all you
| need! You'd have to consider each user before making a
| recommendation about production-readiness.
|
| Instead the author offers the software AS-IS and you can
| decide for yourself. The author doesn't owe anyone
| anything, least of all a personal consultation about
| whether using the software is prudent.
| jjav wrote:
| No, the license means exactly what it says.
|
| An open source project (in most licenses) offers zero
| assurance of it being usable for production and that's what
| it means. If you want to use it for production you need to
| either (a) do whatever evaluations you feel necessary to
| ensure it will be stable for production for your needs, or
| (b) pay the authors for a signed support contract so they
| take on that responsibility.
| mattgreenrocks wrote:
| Sounds rather uncharitable. If that's what you think, then
| maybe open source software is not a good fit for use in
| your projects. Which is totally fine! Some domains benefit
| from having most of the code immediately at hand and under
| your control.
| cweagans wrote:
| You beat me to it :)
| cweagans wrote:
| I would imagine that much of the software that you download
| from Github doesn't claim to be production ready. Many open
| source licenses include language like this:
|
| > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
| CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
| INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
| MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
| DISCLAIMED.
|
| What you choose to put into your production environment is on
| you. Full stop.
| GoToRO wrote:
| why do they hide what the real state is under "as is". "as
| is" can mean that it is great or that it is shit. So "as is"
| is not enough if you really want to be honest with people.
| But they don't want to be honest, they want to be famous and
| a little bit of "hide the garbage under the rug" doesn't hurt
| right? Well it does.
| jjav wrote:
| There's no hiding, it is about responsibility.
|
| If you want to take it for free, then it is 100% on you to
| figure out if it's going to meet your needs and all the
| consequences (fixing any problems that may arise) are on
| your shoulders.
|
| If you don't prefer that, you have the option to try to
| negotiate a support contract with the authors, for suitable
| payment.
|
| What you can't get is assurance of production readyness for
| free.
| cweagans wrote:
| It's not about honesty or fame. The author does not and
| _can not_ know if the code is going to be good for your use
| case. Only you can know that. Evaluate it yourself and see
| if it works for you. If it doesn 't, don't use it. It's
| really that simple.
| GoToRO wrote:
| If they can not know their software is good or bad just
| please choose another profession.
| TheCoelacanth wrote:
| If you want assurances about the quality of software
| you're using, pay for a support contract. You can't
| expect assurances like that on something you got for
| free.
| unionpivo wrote:
| Your view of software seems to be very limited.
|
| There is plenty of good software out there, that is only
| useful in limited.
|
| I wrote code for small drone. If you don't know what you
| are doing you can easily burn down your house, with one
| of those (lipo are no joke).
|
| SQLlight is great software, but if you try using it in
| wrong situation, you are going to have a problem.
|
| In my experience for most of the software, the only
| answer is: it depends on what you are doing.
|
| And sometimes even not so good software is best solution
| for a problem.
| rodgerd wrote:
| If you aren't competent to evaluate whether software is
| production ready, choose another profession.
| tremon wrote:
| "as is" is a specific legal term in the USA:
| https://definitions.uslegal.com/a/as-is/
|
| _As-is is a term used in warranty law to disclaim the
| seller 's liability for faults in the item sold. The buyer
| accepts the item in the present condition, whether the
| faults are apparent or not_
| BeetleB wrote:
| > I agree with him with one condition: does your project have a
| clear warning at the top of the readme that your project is not
| production ready? if no, then it's on you.
|
| Beyond what people have pointed out about the license:
|
| Why should "production ready" be the default, and they have to
| put an explicit "Not production ready" if it isn't? Why not the
| other way round? Given that probably over 95% of projects on
| Github are not even close to production ready, the expectation
| should be the other way round: If they don't make claims it is
| production ready, then you should assume it isn't.
| Pieman103021 wrote:
| Archive -
| https://web.archive.org/web/20220105000136/https://joeldenni...
| lloydatkinson wrote:
| Are you expecting the author to delete it?
| amflare wrote:
| Archive links allow others to read the article if the site
| suffers a Hug of Death from hitting the front page of HN.
| gkbrk wrote:
| Case in point, the link isn't loading for me right now.
| Seems to be hugged to death.
| YATA0 wrote:
| [deleted]
| newshorts wrote:
| Honestly, I don't understand the entitlement that causes someone
| to have to write this.
|
| Having experienced the "overwhelmed with requests" thing myself,
| I now find myself thinking anyone who becomes demanding of open
| source maintainers is not seeing reality. These folks have day
| jobs, they don't work for you.
|
| If you've implemented my library in a mission critical part of
| your system, then feel free to fork & fix or pony up the dough.
| Otherwise you'll get the update (if it should be updated at all)
| when/if I have a minute.
|
| This might be a bit hostile but truly, c'mon people.
| NorwegianDude wrote:
| That's not hostile at all. If someone decides it's best to use
| your code then you have already helped them out. Expecting you
| to do work for free for them because you already did something
| useful for them is just stupid.
| 89vision wrote:
| I don't think this is hostile in the slightest. Nobody should
| expect free work
| [deleted]
| jeff-davis wrote:
| I suggest cultivating a sense of shared ownership. The author is
| trying to do that, which is great, but it seems like it's not
| there yet.
|
| That's true of open source as well as proprietary development. Do
| you want other engineers to constantly contact you because you're
| "the $feature guy"? Or customers to do so?
|
| No, you want a process and a team/community.
| LAC-Tech wrote:
| Stuff like this is why I've never bothered to promote any of the
| open source stuff I've released.
|
| Worst case scenario - people tell me my ideas are dumb and xyz
| does it better (I'm probably aware of xyz and found it lacking).
|
| Best case scenario - the situation in TFA happens, where people
| act like I owe them something.
| NorwegianDude wrote:
| There is a lot of idiots out there who expects you to work for
| them and help them fix their issues just because you made your
| code public for those who find it useful. Just look at some of
| the answers, even here on HN.
|
| One should be happy for the work that people do make available
| for others. If you're not paying for it and it's run by people
| who just want to make something cool then you should be prepared
| to contribute if you want someone to go out of their way to help
| you.
|
| You don't have to contribute financially or by writing/fixing
| code. If you need help with a bug, make sure you write good bug
| reports, and be patient.
|
| Also, if you don't want spam, just turn off notifications for non
| important things and limit the communication channels to
| something you'll be able to control. That's the beauty of digital
| communication: you control exactly how and when people can get in
| touch with you.
| lamontcg wrote:
| Once again I wish github would allow the ability to limit who
| could open issues and PRs in order to do development in the open
| with a trusted/vetted set of collaborators without being subject
| to every zero-effort bug report from users.
| willcipriano wrote:
| I'm shocked that it doesn't. What would you do if you were
| being harassed?
| TingPing wrote:
| You can block specific users and you can temporarily limit
| all interactions if getting spammed.
| bsder wrote:
| I'm also not enamored of the fact that you can log into
| Github/Gitlab/etc. with accounts from everywhere
| (Gmail/Facebook/Twitter/etc.).
|
| I suspect that making someone go through the signup dance
| stopped a _LOT_ of the worst level of morons.
|
| Is there a code hosting service that allows public viewing but
| still forces people to sign up for an account before being able
| to do actions?
| yjftsjthsd-h wrote:
| Maybe sourcehut?
| inglor wrote:
| You can already turn on repository interaction limits limiting
| issues/PRs to collaborators. It needs to be re-enabled every 6
| months https://docs.github.com/en/communities/moderating-
| comments-a...
| brunoborges wrote:
| It's not the same thing, because of the flow:
|
| - developer finds a cool project - developer consumes the
| cool project - developer finds opportunity for bug fix or
| enhancement - developer forks and starts working on the
| enhancements - developer spends hours/days writing code -
| developer submits a PR - developer gets a notification (upon
| filling the PR, or after, from a bot) - developer is now
| extremely frustrated - developer complains - maintainers and
| the developer start debating - the Pull Request storm goes
| viral - developer threatens to stop using cool project -
| maintainers handle the situation poorly (they are coders, not
| Public Relations people) - the community makes things worse
|
| And so on...
| bachmeier wrote:
| I don't understand. You have "developer forks". Everything
| after that is irrelevant. That's the whole point of open
| source.
| kccqzy wrote:
| On GitHub a fork is a lightweight thing. People fork the
| repo in order to contribute because they can't push to
| the original repo. It's not like you are philosophically
| against Emacs and decide to fork it to produce XEmacs.
| bachmeier wrote:
| Just as I don't understand the original comment, I also
| don't understand yours. You don't need to push to the
| original repo because open source allows you to make your
| fork available to others. The developer of the original
| has a right to decide to accept your changes or not, so I
| fail to see why it matters that your PR isn't accepted.
| Nadya wrote:
| Maintaining a fork and maintaining a single feature of a
| project are two different levels of commitment and you
| can want to do one without doing the other although all
| too often people want to contribute a feature and then
| not provide support for it and expect the project
| maintainer to now maintain the contributed code. But
| that's a different issue (and why many maintainers
| sometimes don't accept random PR's even if the code
| itself is fine).
|
| > You don't need to push to the original repo because
| open source allows you to make your fork available to
| others.
|
| This is simply not true - not all open source software is
| copyleft. You can have restrictive licensing regarding
| use and/or distribution and still be open source.
| bachmeier wrote:
| > This is simply not true - not all open source software
| is copyleft. You can have restrictive licensing regarding
| use and/or distribution and still be open source.
|
| Well, of course you can adopt any definition of "open
| source" you want, but I'm using the OSI definition, which
| states:
|
| "The license must allow modifications and derived works,
| and must allow them to be distributed under the same
| terms as the license of the original software."
|
| You are referring to "source available", for which they
| offer the clarification:
|
| "Open source doesn't just mean access to the source
| code."
| jrochkind1 wrote:
| Y'all are talking about possibly _three_ different
| things.
|
| "Source available" does not mean anything about a license
| at all. It literally just means the source is
| available... to someone.
|
| Open source generally means it must have a license that
| allows modifications and derived works. It is more than
| "source available" it means that a public license to use
| and redistribute the software is available. "source
| available" does not necessarily mean you have a free
| license to use or distribute the software, or modify it
| and distribute the modifications. "open source" does. The
| Open Source Institute has tried to standardize a
| definition. https://opensource.org/osd
|
| "copyleft" is sometimes used to mean something _more_
| than some "open source". Richard Stallman has promoted
| these sense of "copyleft". Like GNU license as opposed to
| apache. Both are open source -- nobody says apache
| license isn't open source right? Open source licenses
| that aren't "copyleft" are sometimes called "permissive".
| Here's one description of it that will suffice:
|
| > 3. Is the Apache considered copyleft?
|
| > Copyleft licenses require the derivative works or
| modified versions of existing software to be released
| under the same license. The Apache License doesn't have
| any such requirements. It's a permissive license. It
| permits you to release the modified parts of the code
| under any license of your choice. However, you are
| required to release all the unmodified parts of the
| software under the same license (the Apache License).
|
| --https://www.whitesourcesoftware.com/resources/blog/top-
| 10-ap...
|
| So, no, "source available" is _definitely_ not the same
| thing as "open source" -- all open source may be "source
| available", but things described as just "source
| available" usually are _not_ open source. The source
| might be available to you, but you might not be allowed
| to use it (at all, or in certain ways) without paying,
| and you might not be allowed to redistribute derived
| works.
|
| And "copyleft" is usually used as a subset of "open
| source", for restrictive/"viral" licenses.
|
| I have no idea what any of this has to do with where this
| discussion began -- but yes, anything that's open source,
| copyleft or not, gives you the right to make a variaton
| of the software, use that variation, and distribute it. I
| think that is part of the accepted definition of open
| source. "Source available" software may not give you this
| right.
| Nadya wrote:
| There is a reason FLOSS exists as a term to differentiate
| itself from OSS and I think the ideological differences
| between the two are important. So does Bruce Perens, the
| co-founder of OSI and the author of the Debian Social
| Contract of which the OSI definition was based off: https
| ://web.archive.org/web/20140716055445/https://lists.deb..
| .
|
| This was back in 1999 - it's been over 20 years and "OSS"
| has only been muddied further and further to mean "source
| available" since.
|
| Pedantry aside tremon's response sums it up well:
| "Feature branch hosted in a separate repository."
| jrochkind1 wrote:
| The post you cite by Perens doesn't seem to mention the
| term "FLOSS" (or spelled out), right?
|
| I have seen "FLOSS" used as an umbrella term for ALL of
| it, that is anything that is open source is also "FLOSS".
| But you are saying it exists to _differentiate_ from
| "open source"? Huh. Just to muddy the waters yet further.
| Nadya wrote:
| It doesn't use the term directly, no. Because to hackers,
| especially back in 1999, Free and Open Source were one in
| the same. It was just a difference of branding. However
| Bruce differentiates between "Open Source" and "Free
| Software" in writing and he only does so because public
| perception of what "Open Source" actually means had
| already been muddied in the year since OSI's founding and
| the freedoms afforded by FLOSS were already being de-
| emphasized and put on the back burner.
|
| To quote Bruce:
|
| > Most hackers know that Free Software and Open Source
| are just two words for the same thing. Unfortunately,
| though, Open Source has de-emphasized the importance of
| the freedoms involved in Free Software.....
|
| > ......Sadly, as I've tended toward promotion of Free
| Software rather than Open Source, Eric Raymond seems to
| be losing his free software focus. The Open Source
| certification mark has already been abused in ways I find
| unconscionable and that I will not abide. I fear that the
| Open Source Initiative is drifting away from the Free
| Sofware values with which we originally created it.
|
| There would be no need to make any kind of distinction
| between Free Software and Open Source if Open Source was
| being _perceived_ as Free Software.
|
| OSI was and always will be a marketing gimmick [0]
| created to sell the idea of open source to commercially
| interested parties.
|
| > We realized that the Netscape announcement had created
| a precious window of time within which we might finally
| be able to get the corporate world to listen to what we
| have to teach about the superiority of an open
| development process. We realized it was time to dump the
| confrontational attitude that has been associated with
| `free software' in the past and sell the idea strictly on
| the same pragmatic, business-case grounds that motivated
| Netscape. We brainstormed about tactics and a new label.
| Open source, contributed by Chris Peterson, was the best
| thing we came up with.
|
| Not to downplay OSI at all. It was extremely important
| and widely influential in Netscape's journey to becoming
| Firefox and I'd even argue is still important today. But
| the issue centered around what "Free" means ("Free" as in
| freedom - not beer - which is why the term "libre" is
| often used as well) and that "Free Software" already had
| a poor reputation in the business world and so it needed
| to be rebranded. Eric Raymond made it very clear that he
| places importance on phrasing and branding and attributes
| the tactics used by OSI to its success and why the Free
| Software movement failed. [1]
|
| Honestly a comment by Havoc Pennington on that very post,
| dated Jun 28, 1999, sums up the issue perfectly.
|
| >I think Eric's analysis of the facts is basically right.
| i.e. the "open source as business" stuff has gotten us a
| lot of popularity. The danger is that we fall for our own
| marketing program. That is, new community members join,
| and we have to say "we didn't really mean that. Really we
| meant freedom. The business stuff is for the suits." An
| increasing number of new members just don't understand
| freedom, or copyright, or anything like that; they joined
| "Linux," not "GNU."
|
| [0] http://web.archive.org/web/19981206185148/http://www.
| opensou...
|
| [1] https://web.archive.org/web/20170630183629/http://www
| .linuxt...
| tremon wrote:
| _Just as I don 't understand the original comment, I also
| don't understand yours_
|
| The way Github e.a. use forks dilutes the larger meaning
| of the word, that's what this thread is about. When
| people used to talk about forks, they always mean a
| community fracture over differences of opinion: gcc vs
| egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede,
| glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs
| mate.
|
| The common-use term of "fork" on github has nothing to do
| with divergence of development, it's just a band-aid for
| lack of contributor access control. I can understand why
| people don't like github's use of forks, and that has
| nothing to do with what the license "allows" or not: if
| it's not a divergent development line, it's not a fork,
| it's a clone at best. In most cases, I'd say it's just a
| feature branch hosted in a different repository.
|
| Calling something a fork implies long-term viability (or
| at least the intention) as an alternative to the original
| repo. That doesn't sound like a realistic description of
| most cloned repo's on Github to me.
| theobeers wrote:
| "Feature branch hosted in a separate repository" is a
| very good way of putting it.
| jenscow wrote:
| Perhaps the developer should have discussed their ideas
| before investing their time, if they're going to be upset
| about their unsolicited code being rejected.
| rectang wrote:
| The maintainer still has to deal with the negative
| interaction even if in some cosmic sense the contributor
| could have known better. A workflow design which ensures
| that such negative interactions take place is
| structurally flawed.
| jrochkind1 wrote:
| If issues/PRs were limited to collaborators, wouldn't they
| not be able to submit a PR at all?
| lamontcg wrote:
| That isn't the same thing. It is temporary. You can also only
| limit to existing users (blocking only new GH users which is
| useless), or limit to contributors (people who have merged
| commits in the main branch), or limit to users with write
| access. I want to retain sole write access but allow issues
| to be cut by trusted users who have never submitted PRs or
| code. I also want it permanent and not temporary.
| akvadrako wrote:
| You don't need to use github, especially when you don't want
| the public making issues.
| lamontcg wrote:
| 800# gorilla. don't think gitlab supports this either. that
| probably leaves self-hosting and all the brittleness and pain
| around that.
| YorickPeterse wrote:
| Correct, there's no way to restrict GitLab merge requests
| to trusted users, while still allowing others to view merge
| requests. It's either visible/accessible to all, or only to
| project members.
| legobmw99 wrote:
| GitLab can have this "feature" if the accounts are locked
| behind an entity like a school which doesn't allow
| arbitrary users to make a new account
| qbasic_forever wrote:
| It would be nice to make the "open source, but closed to
| contributions/collaborators" model like SQLite and others
| (lightstream, etc) follow more of a first class citizen on
| github.
| mtlynch wrote:
| Small sidenote: Litestream loosened their contribution
| policy, and they now accept bugfixes but not new features:
|
| https://github.com/benbjohnson/litestream#contribution-
| polic...
| lloydatkinson wrote:
| Bots that close or even delete issues where the issue template
| hasn't been filled in help a lot.
| einpoklum wrote:
| > I am contacted dozens of times every week with varying requests
| to answer people's questions
|
| Occasionally happens to me. I mean, not dozens of times a week,
| but I've had a few weeks with more than a dozen times.
|
| > fix bugs
|
| "Please file an issue at http://the.issue.tracker/wherever"
|
| > or build new features
|
| "Please file an issue at http://the.issue.tracker/wherever"
|
| > set up consultations
|
| So, this one is interesting. I mean, it almost never happens to
| me, and certainly not w.r.t. my FOSS specifically. If I were
| looking for work, this would be a boon, would it not? And if I'm
| fully booked, then:
|
| "I am currently not available for consultancy. You may inquire
| again, if relevant, in ____ months."
|
| > or discuss business opportunities.
|
| "I'm sorry, not interested. Good luck with your business."
|
| Although I guess if there were dozens of these emails per week, I
| would create a private email box and keep the existing one only
| for FOSS-support-related business, attending to it every couple
| of weeks or so. And perhaps create an auto-reply with the above
| replies :-)
| lloydatkinson wrote:
| Is this person OK? Doesn't seem it. I use single-spa. I'm now
| worrying about it's future with the sentiments and apparent
| dislike of users expressed here.
| macintux wrote:
| I don't see a dislike of users, just a dislike of the stress
| that being an open source maintainer tends to place on people.
| sfink wrote:
| That wasn't my impression from reading it. The writeup actually
| seemed very reasonable to me. They perhaps sound like they're
| having a bit more trouble than many at handling the onslaught
| and saying no, but given that, this felt like a fine way to set
| things up.
|
| So I'm curious: what in the writeup indicates a dislike of
| users?
| c0nfused wrote:
| Probably not. I think there is a difference between having
| guidelines for how to.contact you is not dislike if users.
|
| Waking up at 4 am to reply to a poorly worded bug report with a
| demand you fix it immediately is exhausting and sucks your will
| to live
| TheTaytay wrote:
| I got the opposite read regarding their mental health. This was
| a very clear and well thought out statement of reasonable
| boundaries, especially for someone volunteering their time. I
| admire them for it.
| ChrisMarshallNY wrote:
| I didn't get that vibe.
|
| Seems to me, that he wants to keep going on it, but isn't
| really a "people person," and wants to control his agenda.
|
| I can respect that.
|
| I managed an open-source project for a decade, that was
| designed to serve an ... _interesting_ ... demographic.
|
| I think many of the folks here, would have defecated masonry,
| if they got some of the contacts that I did.
|
| But I'm a fairly tough old coot. I held my own. It wasn't
| pleasant, though, and I learned a great deal, about interacting
| with ... _interesting_ ... people.
| qbasic_forever wrote:
| Do you not see the irony that as a user of their free software
| you completely missed the point of their post that is basically
| saying, the people using my software are asking so much and
| giving so little that I'm burning out?
| goostavos wrote:
| This person is more than OK. They're learning how to set
| boundaries and not let crappy people bother them.
|
| Open Source will eat your soul if you let it. Low effort drive
| by issues, questions, or comments are crushing. On my humble
| project, something like 40% of people who open issues
| _completely ignore the issue template_ , which means every.
| single. conversation. begins with asking for the bare minimum
| of details needed to even help them. Then you've got PRs with
| literally zero info, which you're expected to spend time
| reviewing / understanding.
|
| Some people will even violate the Github boundary and email you
| directly to ask why their issue isn't being responded to, or
| why their PR isn't getting merged, or whatever. Honestly? Fuck
| these people.
|
| OP is spot on.
| rodgerd wrote:
| > They're learning how to set boundaries and not let crappy
| people bother them.
|
| Abusive mindsets parse boundaries as an illness. So saying
| that someone "seems unwell" simply because they want
| reasonable boundaries is definitely telling on oneself.
| Crazyontap wrote:
| I think there should be term like suffering from open-source
| fatigue.
|
| Being an active open source dev myself I can relate to this but
| at the same time I also have been on the other side of the fence
| when my oss projects didn't get a lot of traction and any mention
| from anyone, even if it was an issue, got me really excited and
| it also kinda validated my efforts.
|
| It's like being a mini celebrity feeling happy when somebody asks
| for your first autograph but as you become more successful more
| people want your time and attention and then you don't want it
| anymore. Also unlike being a celebrity you may get some fame but
| rarely any fortune, so that makes it all the more easy to get
| annoyed when people try to eat your attention for their own
| benefit.
| ascar wrote:
| > Also unlike being a celebrity you may get some fame but
| rarely any fortune
|
| I know this isn't your main point, but afaik most low-level
| celebrities barely make money from it either. So it's actually
| even more similar than you thought.
| xiwenc wrote:
| Why not grow the maintainers group to multiple people? A trusted
| group of people that share the vision of the project. This way
| the project becomes a living thing that doesn't depend on the
| goodwill of a single person. And that single person would not be
| overwhelmed.
|
| People are not entitled for support but bringing something out as
| open source does come with some responsibilities. If not when
| others fork it the original author gets upset others stealing
| their project (assumption here).
| TonyTrapp wrote:
| There are many, many projects where "simply adding more
| maintainers" is not possible at all, i.e. there are no people
| that you personally can trust to do the right thing, and that
| have the necessary experience. For various projects that I
| maintain, I couldn't name a single person that would have the
| skill and would actually want to take over. Granted they may
| not be as popular as this persons's repositories, but still -
| this claim is not generally true.
| bwindels wrote:
| > bringing something out as open source does come with some
| responsibilities.
|
| No, it does not.
| moron4hire wrote:
| I had a very similar experience with running open source
| projects. I was getting frustrated with people not contributing
| in any significant way. Functionally useless bug reports. Coding
| bootcamp students submitting PRs that did nothing but change some
| grammar in the README (and never actually changing it correctly).
| Feature requests for things I had explained in several other
| issues that I would never do. Requests for support in setting up
| _other_ people 's software.
|
| But if people are contacting me about my project, they must be
| using it, right? Isn't that the point? Can't I just ignore the
| noise? What's the problem?
|
| I eventually realized my motivations for developing _open source_
| software were rooted in vanity. Just making programs is something
| I do all the time, I find it very rewarding. But the part about
| open sourcing it, that was the vanity.
|
| Before opening the project, nobody else was contributing anything
| to it, either. After opening it, all that changed was that my
| expectations for how people would react to it were not met.
| Expecting people to want to use my software in exactly the way I
| wanted was a hell of a lot of arrogance. Those people who were
| requesting features, they weren't "wrong", they just wanted
| different software. More like a service that did the things my
| software could enable, rather than building things with my
| software.
|
| I don't write the software to get rich or escape a dead-end job.
| I used to have that fantasy, but nowadays life is pretty happy,
| and I also have realized the fantasy was always a myth, anyway.
| So in the end, the difference between writing software and
| writing _open source_ software is nothing more than me wanting
| recognition for the thing I created; aka a vain search for glory.
|
| I didn't like that view of myself, so I stopped opening my
| software.
| cubano wrote:
| > I eventually realized my motivations for developing open
| source software were rooted in vanity.
|
| Bingo. The hard-earned wisdom of this insight right here almost
| completely explains all the internal issues the OP was feeling
| when he wrote his rather over-the-top post.
|
| Yeah, it sucks to realize that your just as human as the next
| guy and that your motives aren't always as pure as you wish
| they were, but there is nothing at all wrong with being proud
| and wanting to be noticed for abilities.
|
| Figuring out what path works for you AFTER realizing your
| motives aren't pure is how one solves the open-source user
| issue.
| travisjungroth wrote:
| You're saying no one uses your software whether it's open or
| closed, you just got annoying "contributions". How did you know
| no one was using it? How would you know if someone was?
| moron4hire wrote:
| No, I didn't say people weren't _using_ the software. I could
| see that in a lot of different ways: how many people were
| active on the project site, how many people had forked the
| project on github, etc.
|
| My point was that my reaction to things like feature requests
| I didn't want to build was a signal that I wasn't interested
| in building _just_ a user base for the project. If what I
| were interested in were building a project that people wanted
| to use, could sell to them, etc., then I would discard my
| notions about what _I_ wanted to build and I 'd build what
| people wanted. That was the epiphany I had. I realized I had
| been lying to myself about my motivations. I realized that my
| actions proved I didn't really care about getting people to
| just _use_ the software.
|
| Because I was so annoyed by the lack of contribution, despite
| the obvious signals that people were using the software, I
| (eventually) realized that my true goal was for people to
| interact with my code, not my program. There's a difference
| there. Any feature in a program can be implemented in any
| number of ways. But there's necessarily only one way that
| it's implemented in _my_ program. Thus to be more focused on
| contributions than usage implies that I care more about how
| people see my implementation of the features than the
| features themselves.
|
| I didn't start these projects thinking, "let me make a thing
| that will prove my prowess as a developer". I made the things
| to scratch some personal itch. The software on its own
| fulfills that particular need.
|
| The act of open sourcing it was a different thing entirely.
| It's not trivial to open source a project; there's a lot of
| work in trying to prepare it for use by other people. Why go
| through all of that? What need did I expect opening the code
| to fulfill for me? Opening code doesn't attract users. So few
| users care if a project is open or not that they can safely
| be ignored as a rounding error. So why focus time on opening
| the code, verus any other action I could take with my time?
|
| Thus the realization that I had been deluding myself.
| reflexco wrote:
| Some licenses may require build instructions, but if all
| you want is to open your source code so that other people
| can read it, you can just do that. Remove secrets, publish
| the code, and you're done.
|
| People can figure out how to build it if they want, it's
| not your problem or responsibility unless you want it to
| be.
|
| See Keybase or Signal for instance.
| jka wrote:
| > Because I was so annoyed by the lack of contribution,
| despite the obvious signals that people were using the
| software, I (eventually) realized that my true goal was for
| people to interact with my code, not my program.
|
| That's a neat observation. My theory -- hard to prove --
| would be that if you leave the code open for long enough
| (regardless or not of whether you pay attention to
| contributions, and how many of them there are), you'll find
| some keen soul further down the road who finds and repairs
| some kind of compatibility issue, security/privacy problem,
| or similar.
|
| > So few users care if a project is open or not that they
| can safely be ignored as a rounding error.
|
| I can near-guarantee that for users who understand that
| software can do whatever it wants on their system, within
| the capabilities of the runtime environment and as
| instructed, then when those users are provided with the
| option to be able to see the corresponding code or not,
| they'll choose to have it available to them. In an
| enterprise context: it can sway vendor selection.
|
| That's an increasing percentage of users today, I think.
| Perhaps it was the case a decade or two ago that people
| thought of software as windowed applications on their
| desktop; nowadays I reckon that more people have software
| developers within their extended social networks, and from
| that exposure they have a little bit more of a sense for
| how computers and code work.
|
| And in response to one of your parent comments:
|
| > I didn't like that view of myself, so I stopped opening
| my software.
|
| Totally understandable. Don't forget the fact that you have
| an opportunity (not a responsibility, by any means) to
| teach and share code with current and future generations of
| developers.
|
| They might discover some relevant snippet of yours through
| code search and find exactly what they need to solve a
| problem. Perhaps they'll credit you; perhaps they won't
| (perhaps they won't realize or be in the mindset that it's
| worthwhile (and/or important) to credit people for their
| work) - either way you'll have helped someone with their
| day.
___________________________________________________________________
(page generated 2022-03-16 23:00 UTC)