[HN Gopher] How to support open-source software and stay sane
___________________________________________________________________
How to support open-source software and stay sane
Author : rbanffy
Score : 27 points
Date : 2022-08-03 19:51 UTC (3 hours ago)
(HTM) web link (www.nature.com)
(TXT) w3m dump (www.nature.com)
| manholio wrote:
| What we need is an time-bombed open source license, that allows a
| limited exclusivity period for the author during which they can
| charge for the software. After that time expires, say 3 years,
| the software reverts to a free shareable license, that anyone can
| fork into their own commercial, 3-year time bombed projects.
|
| Dangle the carrot and let working people make a living, but force
| them to give back and prevent them from building closed source
| proprietary empires fueled by vendor lock-in.
|
| There is a certain type of software, for example professional
| tools use by non-programmers - graphic editors - where
| traditional open source models, support contract or volunteer
| developers, can't work. If you won't be able to charge for copy,
| such software will never be written in an open variant.
| freeqaz wrote:
| That is the goal of the Business Source License[0] which has
| been gaining popularity recently. It's still a bit tricky to
| "adopt" into organizations because it is not usually on the
| "approved license list", but it's a pretty good middle-ground
| imo. A lot of companies are starting to move behind it like
| CockroachDB, MariaDB, Couchbase, and many others.
|
| I'm less of a fan of another license that's gaining popularity
| too, the "Server-Side Public License" (SSPL)[1], with projects
| like Airbyte and MongoDB because it doesn't have the "time
| bomb" aspect that BSL has. If there was a license that were in
| the middle between the two (SSPL but w/ a time bomb) I'd be
| pretty stoked.
|
| Until then though, we'll just have to live with custom
| "Additional Use Grants" in BSL to carve out who can use it.
|
| 0: https://mariadb.com/bsl-faq-mariadb/
|
| 1: https://www.mongodb.com/licensing/server-side-public-
| license...
| yubozhao wrote:
| Curious about your reason behind being less of a fan of the
| SSPL license. Can you elaborate more?
|
| disclosure: I have a repo using the SSPL license
| JoshTriplett wrote:
| > time-bombed open source license
|
| That's contradictory by definition; such a license would not be
| Open Source. (With care, the three-years-later version could be
| Open Source, at which point people could build on that.)
| valbaca wrote:
| no, it's not. the source is open, it's support that's
| charged.
| JoshTriplett wrote:
| The comment I was replying to said:
|
| > limited exclusivity period for the author during which
| they can charge for the software
|
| It didn't say "support for the software" (and in any case
| anyone can provide support for the software).
| freeqaz wrote:
| I wish that this article had focused more on the "how to" aspect
| of this problem and less on the "what" part. It feels a little
| muddied between trying to explain the problem space (researchers
| re-using code) and the "steps" involved (write clear code + docs,
| use Git).
|
| As somebody that runs a semi-popular Open Source project[0], I am
| very aware of the painstaking task of taking a "hacky script on
| my machine" and turning it into something public that others can
| not only use, but trust enough to _depend_ on too.
|
| Here is a rough checklist of tasks that come to mind:
|
| - Write a Readme with a description of what the project is (help
| Google index it for future search)
|
| - Publish a Docker image that can build the whole project and
| produce a binary or run the server (this is a massive PITA to get
| setup -- once you do this, setting up CI becomes very easy)
| - Ideally there is a Docker image with a small POC app too (which
| is often more useful that docs are imo)
|
| - Put the project into Awesome Lists so that people will actually
| find it (also helps with SEO)
|
| - Add a license to the repo and, if you really want people to
| trust it, add license headers to every file (I see _so many_
| projects without even a LICENSE file. Without this, it's illegal
| to use the code at all!)
|
| Beyond all of that, Docs help a lot too, as does a "legit"
| looking website, but you can get away with pretty crappy docs if
| you do all of the above.
|
| 0: https://github.com/lunasec-io/lunasec/
| huepfebein wrote:
| Documentation, preferably including FAQ for bigger projects, is
| key. Saves time and energy for users/customers (current or
| potential), future maintainers, other developers and support
| teams.
|
| Another recommendation: Limit your dependencies to what is
| strictly necessary.
| _jal wrote:
| > but you can get away with pretty crappy docs if you do all of
| the above
|
| Depends on your audience, I suspect. When evaluating something
| for use, the first thing I look at are the docs. No docs, or
| just videos pretending to be documentation makes it super easy
| to skip and move on to the next possibility. Crappy docs means
| I only come back to it if everything else is worse.
___________________________________________________________________
(page generated 2022-08-03 23:00 UTC)