“The shortness of MIT and BSD [licenses] are reassuring only until you actually try to understand them, and find you need a decoder ring. The terms are actually dangerous if you read them without knowing you need that decoder ring.”
I will not participate in #Hacktoberfest this year, although contributing to #OpenSource and #FreeSoftware is my day job. First, I already have enough t-shirts. But second, the ecosystem I use on a daily basis is mostly made up of projects that use GitLab, or BitBucket, or sr.ht, or Fossil, or sending patches by mail, or GNU Savannah, or (good grief!) even SourceForge. I think only two of the projects I contributed last year were on GitHub.
The #FOSS world is so much bigger. Don't forget that.
Trump, Huawei, Open Source
The Huawei fallout has reached open source projects -.-
Upstream developers: changing your already released tarballs is an antipattern and breaks reproducabilty. We all make errors, we don't hate you for releasing a -repack1.tar.gz :)
And I wondered whether there is a correlation of "our code" projects being organised socially in a way that makes it difficult for new users to contribute, and as such "prove their worth to the community" by taking all those extra hurdles to get their contribution in. These projects would possibly also be more opposed to explicit docs or codes of conduct.
So here's an unproven hypothesis, there's probably a PhD or master's thesis hidden in there somewhere :)
At #ELCE18 #OSSummit I heard a talk today about one-time contributions to #opensource projects . The main focus was what to do best to get your contribution accepted, but it also included a categorisation of projects into "our code" projects, which basically ask why your contribution is worthy enough to be accepted, and "your code" projects that ask "how can we maintain your contribution in the long term".
 Diary of a Drive by Coder, by James Bottomley, https://osseu18.sched.com/event/FxWu
When writing change logs for version control, definitely include the "why".
When submitting patches, the reason for a change can tell the maintainers about your use case, which bugs it fixes, and also about potential regressions in other branches.
In five years, everyone can see what you did, but without an included reason, it will be lost and need to be guessed.
When hunting for bugs (e.g. via git-bisect), you'll want to know whether a commit can be reverted safely.
I guess it's time for #introductions.
My current job is working with #OpenSource and #Linux on #embeddedSystems, in my spare time I'm involved in @stratum0, our #hackerspace. Other interests include #openstreetmap, #plainTextAccounting and learning languages for fun – I'm fluent in #german and #english, can also understand #french and #dutch, and read a lot of other scripts to some extent. Mi ankaŭ provas studi la #Esperanton.
chaos.social – a Fediverse instance for & by the Chaos community