575 Matching Annotations
  1. Jul 2022
    1. Dec 13, 2021 — I want to talk about how open source has in the most cases, been turned into exploitation by the biggest organisations in the world.exploiting meaningwhat is an exploit in computer securityit exploit definition owaspexploit vs vulnerabilityexploit in cyber security exampletypes of exploitsPeople also search for
  2. Jun 2022
  3. May 2022
    1. Projects like the Open Journal System, Manifold or Scalar are based on a distributed model that allow anyone to download and deploy the software (Maxwell et al., 2019), offering an alternative to the commercial entities that dominate the scholarly communication ecosystem.

      Might Hypothes.is also be included with this list? Though it could go a bit further toward packaging and making it more easily available to self-hosters.

  4. Mar 2022
  5. rom-rb.org rom-rb.org
  6. Feb 2022
    1. “Well, it’s Open Source, I guess I could go download the source code… but… meh, it’s so far out of my way, not worth it,” and the urge fizzles out. I think that a lot of potential human creativity is being wasted this way.

      This reminds me of physical tinkering, like building or fixing your own small furniture. That's also hard with the products we often buy today -- it's difficult to fix minature electronics which are meant to be replaced.

      But with software (esp. open source) it could be easier, as everyone can have the same tools. I very much resonate with the idea of tinkering more and using less standards.

    2. Making changes or additions to the standard library was as easy as making changes to my own code

      For many people, making changes to code at all is hard. The few times I remember actually forking a library to add functionality, it meant hours reading into the codebase and polishing my change to commit it upstream.

      I like the author's argument, but it's not not just the friction to view source code -- many technical architectures are also needlessly complex or non-standard.

  7. Jan 2022
    1. In my very next letter, Letter XVI, I reported that Conor had perhaps heard our concerns about the cult connotations, and also decided to move away from the use of it too.

      I always thought of the #RoamCult hashtag as a bit tongue-in-cheek, but certainly something with a more positive framing could be chosen.

      It's interesting to hear that the project seems to have gone quiet and that the perception is that people are leaving for other projects (many of them open source, which is one of the spaces many of the early adopters were already working in).

      There's definitely a drive in a lot of this space for people to own their own data given it's direct value to them over other (more social facing) tools.

  8. Dec 2021
    1. oh by the way did i tell you it's hard like probably it's it's also really hard but i really don't want to stop here on a on a low note

      This is a great video on the reality of open source software. Open source hardware also faces similar funding issues.

      As long as open source is fundamentally dependent on the private sector, it will exist within at best a parasitic relationship. To truly develop an autonomous open source model requires a structural change in funding that allows it to stand alone and apart from corporate sponsorship.

      This is a classic chicken-and-egg situation. We want people to sponsor us, but many of those people also work for the private sector. Governments and NGOs may sponsor us, but they also depend on private sector for tax and donation revenues.

      This requires a much deeper discussion that unpacks the fundamental assumptions that underpin our economic, social and political systems. The structural challenges of funding open source exposes the constraints of our current system.

      Unless we examine the fundamental assumptions by which our current civilization operates, we cannot make the structural changes that would enable open source to reach its full potential, which is maximum access to shared intellectual and material resources for the benefit of all.

    1. Standard algorithms as a reliable engine in SaaS https://en.itpedia.nl/2021/12/06/standaard-algoritmen-als-betrouwbaar-motorblok-in-saas/ The term "Algorithm" has gotten a bad rap in recent years. This is because large tech companies such as Facebook and Google are often accused of threatening our privacy. However, algorithms are an integral part of every application. As is known, SaaS is standard software, which makes use of algorithms just like other software.

      • But what are algorithms anyway?
      • How can we use standard algorithms?
      • How do standard algorithms end up in our software?
      • When is software not an algorithm?
  9. Nov 2021
  10. Oct 2021
  11. Sep 2021
  12. Aug 2021
    1. I joined Caldera in November of 1995, and we certainly used "open source" broadly at that time. We were building software. I can't imagine a world where we did not use the specific phrase "open source software". And we were not alone. The term "Open Source" was used broadly by Linus Torvalds (who at the time was a student...I had dinner with Linus and his then-girlfriend Ute in Germany while he was still a student)

      From Linus Torvalds Remembers the Days Before ‘Open Source’:

      Torvalds counters that “I wouldn’t trust Lyle Ball’s recollection 100% about me… since my girlfriend-at-the-time (now wife) name was Tove, not Ute.”

  13. Jul 2021
    1. Growth hacking and lowest common denominator experiences are their problems, so we should avoid making them our problems, too. We already have various tools for enabling growth: the freedom to use the software for any purpose being one of the most powerful. We can go the other way and provide deeply-specific experiences that solve a small collection of problems incredibly well for a small number of people. Then those people become super-committed fans because no other thing works as well for them as our thing, and they tell their small number of friends, who can not only use this great thing but have the freedom to study how the program works, and change it so it does their computing as they wish—or to get someone to change it for them. Thus the snowball turns into an avalanche.

      This is exactly how I feel about Joplin - the open-source note taking application, developed as an alternative to Evernote.

  14. Jun 2021
    1. I’d still argue that offices can and do produce spontaneous, productive encounters.

      But so does any other form of collaboration. Most of the internet is run by code that was written by people communicating over email and IRC. There was no "open source office" that these people collaborated in.

    1. This, it seems to me, would be something like a readerly utopia. It could even (if we want to get all grand and optimistic) turn out to be a Gutenberg-style revolution — not for writing, this time, but for reading.

      I love the idea of this but implementation, particularly open implementation seems nearly impossible.

      Even getting digital commonplaces to align and register is tough enough much less doing multi-modal registration with the locations that books might live.

    1. Users who have installed it decided to trust me, and I'm not comfortable transferring that trust to someone else on their behalf. However, if you'd like to fork it, feel free.

      Interesting decision... Seems like the project could have been handed off to new maintainers instead of just a dead-end abandoned project and little chance of anyone using it for new projects now.

      Sure you can fork it, but without a clear indication of which of the many forks in the network graph to trust, I doubt few will take the (massively) extra time to evaluate all options and choose an existing fork as a "leader" (or create their own fork) to go with continuing maintenance...

  15. May 2021
  16. Apr 2021
    1. Manifold – Building an Open Source Publishing Platform

      Zach Davis and Matthew Gold

      Re-watching after the conference.

      Manifold

      Use case of showing the process of making the book. The book as a start to finish project rather than just the end product.

      They built the platform while eating their own cooking (or at least doing so with nearby communities).

      Use for this as bookclubs. Embedable audio and video possibilities.

      Use case where people have put journals on the platform and they've grown to add meta data and features to work for that.

      They're allowing people to pull in social media pieces into the platform as well. Perhaps an opportunity to use Webmentions?

      They support epub.

      It can pull in Gutenberg texts.

      Jim Groom talks about the idea of almost using Manifold as an LMS in and of itself. Centering the text as the thing around which we're gathering.

      CUNY Editions of standard e-books with additional resources.Critical editions.

      Using simple tools like Google Docs and then ingest them into Manifold using a YAML file.

      TEI, LaTeX formats and strategies for pulling them in. (Are these actually supported? It wasn't clear.)

      Reclaim Cloud has a container that will run Manifold.

      Zach is a big believer in UX and design as the core of their product.

  17. Mar 2021
    1. Sorry you’re surprised. Issues are filed at about a rate of 1 per day against GLib. Merge requests at a rate of about 1 per 2 days. Each issue or merge request takes a minimum of about 30 minutes (across at least 2 people) to analyse, put together a fix, test it, review it, fix it, review it and merge it. I’d estimate the average is closer to 3 hours than 30 minutes. Even at the fastest rate, it would take 3 working months to clear the backlog of ~1000 issues. I get a small proportion of my working time to spend on GLib (not full time).
    1. The reason we've avoided registering "Cinnamon" as a desktop name is that it opens up issues with many upstream apps that currently OnlyShowIn=Gnome or Gnome;Unity or just Unity. The relationship Mint has with Gnome and Ubuntu isn't genial enough that we could get them to add Cinnamon to their desktop files, so we would have to distribute and maintain separate duplicate .desktop files just for Cinnamon for these upstream packages.
    1. here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.
    1. If JavaScript were detached from the client and server platforms, the pressure of being a monoculture would be lifted — the next iteration of the JavaScript language or run-time would no longer have to please every developer in the world, but instead could focus on pleasing a much smaller audience of developers who love JavaScript and thrive with it, while enabling others to move to alternative languages or run-times.
  18. Feb 2021
    1. note that TRB source code modifications are not proprietary

      In other words, you can build on this software in your proprietary software but can't change the Trailblazer source unless you're willing to contribute it back.

      loophole: I wonder if this will actually just push people to move their code -- which at the core is/would be a direction modification to the source code - out to a separate module. That's so easy to do with Ruby, so this restriction hardly seems like it would have any effect on encouraging contributions.

    1. But all of these attempts misunderstand why the Open Source ecosystem is successful as a whole. The ecosystem of fairly standard licenses provides a level playing field that allows collaboration with low friction, and produces massive value for everyone involved – both to those that contribute and to those that don't. It is not without problems (there are many essential but unsexy projects that are struggling with funding), but introducing more friction won't improve the success of this ecosystem – it will just lead to some parts of the ecosystem to break off.
    2. It turns out that creating and using Free Software is not just good to individuals, but for businesses as well, for example by building upon publicly available components and by collaborating shared software. The term Open Source is a business-friendly rebranding of the Free Software concept. This line of thought was also widely successful, e.g. Firefox/Mozilla was an open sourcing of Netscape software.
  19. Jan 2021
    1. Unfortunately, this probably means a death knoll for this gem, at least I predict it will contribute to its slow trajectory towards insignificance/unknownness/lack-of-users.

      Why? Because it is already the less popular option in this comparison: https://ruby.libhunt.com/compare-premailer-rails-vs-roadie-rails

      and being actively maintained is an important factor in evaluating competing options.

      So of course people will see that the premailer option is the option that is still actively maintained, is still continuing to be improved, and they'll see that this one has been relegated to dormancy/stagnancy/neglect/staleness, which will only amplify the degree/sense of abandonment it already has from its maintainer (only now it will be its users that start to abandon it, as I now have).

    1. unlike a traditional computer, a blockchain computer can offer strong trust guarantees, rooted in the mathematical and game-theoretic properties of the system. A user or developer can trust that a piece of code running on a blockchain computer will continue to behave as designed, even if individual participants in the network change their motivations or try to subvert the system. This means that the control of a blockchain computer can be placed in the hands of a community
    1. Would you work for free? It is a simple but loaded question that requires additional context. Is it working to help a friend do something? Is it work that you would enjoy? Does the act of working for free give you some level of satisfaction? Your gut reaction to the question may have been a hearty, “No,” but many people volunteer for a variety of things all the time, so people will work for free when there is something in it they enjoy.
    2. These developers are not greedy or selfish for wanting funding for their projects. To the contrary, they want funding to keep the project alive. A person has to eat, after all. Funding the project is a means of changing the maintainer’s timeshare—allowing themselves to put time into the project that otherwise would be used for other employment. There is only so much time in a day that a person can otherwise give.
    3. Funding should not be a struggle for open source projects. We embrace open source into our codebases frequently but have yet to fully embrace the idea that funding it actually helps us too. The bug fixes and feature requests need to be implemented, tested, and reviewed by someone who themselves can only put so much time into the project.
  20. Dec 2020
    1. You can also purchase a Nextcould hosting service, which on one hand may not seem any different from giving your photos over to Google or Apple, but there's a significant difference: Nextcloud storage is demonstrably encrypted, with source code to prove it.
    1. Following the model of open-source software, we can enter our ideas and expressions into public discourse

      This also isn't a well-aligned argument. Articles published in a for-profit journal are entered into the public discourse (although obviously not into the public domain). Unless public means "without cost", which I don't think it does.

      We might want to broaden this to include open-access, which is specific to publication models.

    1. With some frameworks, you may find your needs at odds with the enterprise-level goals of a megacorp owner, and you may both benefit and sometimes suffer from their web-scale engineering. Svelte’s future does not depend on the continued delivery of business value to one company, and its direction is shaped in public by volunteers.
  21. Nov 2020
    1. In Rust, we use the "No New Rationale" rule, which says that the decision to merge (or not merge) an RFC is based only on rationale that was presented and debated in public. This avoids accidents where the community feels blindsided by a decision.
    2. I'd like to go with an RFC-based governance model (similar to Rust, Ember or Swift) that looks something like this: new features go through a public RFC that describes the motivation for the change, a detailed implementation description, a description on how to document or teach the change (for kpm, that would roughly be focused around how it affected the usual workflows), any drawbacks or alternatives, and any open questions that should be addressed before merging. the change is discussed until all of the relevant arguments have been debated and the arguments are starting to become repetitive (they "reach a steady state") the RFC goes into "final comment period", allowing people who weren't paying close attention to every proposal to have a chance to weigh in with new arguments. assuming no new arguments are presented, the RFC is merged by consensus of the core team and the feature is implemented. All changes, regardless of their source, go through this process, giving active community members who aren't on the core team an opportunity to participate directly in the future direction of the project. (both because of proposals they submit and ones from the core team that they contribute to)
    1. Express - 19 $ 🏃‍♀️ Skip the Review Queue 🕒 Published in 3 days 💌 Full Customer Support 💚 Support the team

      Wow, after seeing how this site works, I don't like much like it anymore.

      Esp. this below:

      Choose your preferred publish date - 9 $ Feature your project on top for 14 days and get an additional tweet - 19 $

      I hope there is/will be soon a more open/free alternative (like the "awesome" lists that use GitHub PRs instead of an opaque/proprietary submisison form).

  22. Oct 2020
    1. Free to accessFree to reuseFree to reviseFree to remixFree to redistributeThe question becomes, then, what is the relationship between these additional capabilities and what we know about effective teaching and learning? How can we extend, revise, and remix our pedagogy based on these additional capabilities?

      I look at this and think immediatly about the Git model of allowing people to not only fork and reuse/redistribute pieces, but what about the ability to do pull requests to take improvements and push them back up the the source so that everyone potentially benefits?

  23. Sep 2020
    1. The initials fa in the class refer to Font Awesome, an open- source set of icons created by Dave Gandy,23 which further links this project to the open- source community and its ethos of collaboration. Font Awesome gives the community icons for making professional- grade web apps, rendering artifacts and objects legible in the contemporary web design ecology

      Font Awesome est une police d'écriture et un outil d'icônes qui se base sur CSS, LESS et SASS (Wikipédia, « Font Awesome », consulté le 22 septembre 2020).

  24. Aug 2020
    1. GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.
  25. Jul 2020
    1. This isn’t an accident. OpenOffice’s sidebar code was copied and incorporated into LibreOffice. The Apache OpenOffice project uses the Apache License, while the LibreOffice uses a dual LGPLv3 / MPL license. The practical result is LibreOffice can take OpenOffice’s code and incorporate it into LibreOffice — the licenses are compatible. On the other hand, LibreOffice has some features — like font embedding — that don’t appear in OpenOffice. This is because the two different licenses only allow a one-way transfer of code. LibreOffice can incorporate OpenOffice’s code, but OpenOffice can’t incorporate LibreOffice’s code. This is the result of the different licenses the projects chose.

      What part of LGPLv3 / MPL prevents LibreOffice code from being incorporated back into OpenOffice's Apache Licensed code??

    1. A growing number of platforms, vendors, and partners support the AMP Project by providing custom components or offering integration with AMP pages within their platforms.

      I guess AMP is actually open-source software, but it still feels like it's something non-standard. I guess it's just an alternative open standard to the "main" web open standards.

  26. Jun 2020
    1. Unlike Telegram, WhatsApp is not open source, so there’s no way for security researchers to easily check whether there are backdoors in its code. Not only does WhatsApp not publish its code, they do the exact opposite: WhatsApp deliberately obfuscates their apps’ binaries to make sure no one is able to study them thoroughly. 
  27. May 2020
    1. The folks at Netlify created Netlify CMS to fill a gap in the static site generation pipeline. There were some great proprietary headless CMS options, but no real contenders that were open source and extensible—that could turn into a community-built ecosystem like WordPress or Drupal. For that reason, Netlify CMS is made to be community-driven, and has never been locked to the Netlify platform (despite the name).

      Kind of an unfortunate name...

    Tags

    Annotators