Looking deeper, you can see a large amount of issues open, bugs taking months to fix, and pull requests never seem to be merged from outside contributors. Apollo seems unfocused on building the great client package the community wants.

This sort of behaviour indicates to me that Apollo is using open-source merely for marketing and not to make their product better. The company wants you to get familiar with Apollo Client and then buy into their products, not truly open-source software in my opinion. This is one of the negatives of the open-core business model.

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.

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

Happy Third Birthday #24728!

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.

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.

A lightweight text editor written in Lua

Actually, I've decided to stop using labels for a while. A "bug" label gives the impression that someone else is going to fix the problem. We don't have enough volunteers for that (new contributors welcome!). I try to help people working on issues, though. I've spent many hours on this one.

I also sell Sidekiq Pro and Sidekiq Enterprise, extensions to Sidekiq which provide more features, a commercial-friendly license and allow you to support high quality open source development all at the same time.

A good heuristic is to not trust the libraries you did not write either.

In some cases empty can be the simplest replacement for TCL/expect or other similar programming tools because empty:

Rsync was originally written by Andrew Tridgell and is currently maintained by Wayne Davison.

definitely less rough to work with than Devise

It almost feels unreal finishing up this release post. It’s been so long!

After around 3 years of silence, Trailblazer is back with its 2.1 release.

This is not a fork. This is a repository of scripts to automatically build Microsoft's vscode repository into freely-licensed binaries with a community-driven default configuration.

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

Age of a ticket is completely irrelevant as anyone can request anything but the number of developers is limited. If you'd like to see something implemented, please consider providing a patch. Thanks!

Sorry if I sounded rude. I am using Gnome on a daily basis and am highly appreciating all the work anyone has put into it. I was just surprised when I found an AskUbuntu post from 2010 linking to this bug.

Wow 14 years. I still keep stumbling over this issue...

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.

he goes on to talk about third party problems and how you're never guaranteed something is written correctly or that even if it is you don't know if it's the most optimal solution

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.

I suspect you aren't seeing much discussion because those who have a reasonable process in place, and do not consider this situation to be as bad as everyone would have you believe, tend not to comment on it as much.

Unfortunately, this open nature also causes security risks, asevidenced by recent incidents of single packages that brokeor attacked software running on millions of computers.

JavaScript needs to fly from its comfy nest, and learn to survive on its own, on equal terms with other languages and run-times. It’s time to grow up, kid.

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.

PyPy was funded by the European Union being a Specific Targeted Research Project

As of May 24, 2016, antimicro has moved from https://github.com/Ryochan7/antimicro to https://github.com/AntiMicro/antimicro. Additionally, project management has passed from Travis (Ryochan7) to the AntiMicro organization due to Travis having other interests and priorities.

When markets are new and “hot”, they often follow that frenzy of dozens — if not hundreds — of entrants trying to grab market share from each other.

For the $$$ question, nothing comes to mind. These problems i'm hitting up against are larger than a contractor could solve in a few hours of work (which would be hundreds/thousands of dollars).

Yeah, can we pay money to make this go faster? Serious question.

Progress is slow though. I want to change how assets are loaded, the current implementation of "pipelines" is challenging to work with.

I'm trying to get official time at work to dedicate to source maps, and haven't made much progress there.

Still broken, @cannikin. Nobody's on board to investigate, much less fix it. Please do dig in

OpenFaaS is hosted by OpenFaaS Ltd (registration: 11076587), a company which also offers commercial services, homepage sponsorships, and support.

On the “lows” side, I’d say the worst thing was the impact of not being present enough for my family. I was working a full-time job and doing faastRuby on nights and weekends. Here I want to give a big shout out to my wife. She supported me through this and didn’t cut my head off in the process.

markdown-it is the result of the decision of the authors who contributed to 99% of the Remarkable code to move to a project with the same authorship but new leadership (Vitaly and Alex). It's not a fork.

release 0.0.1 after around 5 years.

Licensed under the LGPLv3 license. We also offer a commercial-friendly license.

This project is provided by the LinkedIn Presentation Infrastructure team as open source software

Testing your open source projects will always be free! Seriously. Always. We like to think of it as our way of giving back to a community that connects so many people.

Our mission is to allow people to make money via educational efforts and to dedicate the rest of their time to creating great open source products.

We’re now relaunching PRO, but instead of a paid chat and (never existing) paid documentation, your team gets access to paid gems, our visual editor for workflows, and a commercial license.

And yes, at TRB GmbH, we do pay people to work on OSS

To tell you the truth, the new tracing feature was the original reason why I decided to write 2.1 and make you sit and wait in agony for years. Nevertheless, tracing is simply blowing my mind. I can’t count how many hours and angering rushs of adrenaline I’ve saved since the introduction of the wtf? method and its helpful higher-level stack trace.

note that TRB source code modifications are not proprietary

Trailblazer (TRB) is an Open-Source project. Since we want to keep it that way, we decided to raise awareness for the “cost” of our work - providing new versions and features is incredibly time-consuming for us, but we love what we do.

This creates a win-win situation, you as the user have your peace of mind, and we can continue working with your funds.

Take 3, Previously attempted in 2012 (#8189) and 2015 (#19709). This new version uses ActiveModel Attributes API.

Another recent attempt: #35246

Sorry for the delay, life got in the way. I should have some time to pick this up again next week.

Great thanks to Blake Education for giving us the freedom and time to develop this project in 2013 while working on their project.

This gives them a slight edge but that’s nothing substantial because those fixes eventually reach Ubuntu.

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.

Part of me thinks that open source can be more rewarding to the creators/contributors. But maybe the real contribution is the permanent addition to the tools available to humanity, and if you have the wits, you can make a decent business out of it without tainting open source.

Selling proprietary software is difficult when there is so much gratis Open Source software around.

For a sufficiently successful and industry-relevant open source project, it's possible for the main developers to earn a living e.g. by selling related consulting services.

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.

This is a store we can’t audit, which contains software nobody can patch. If we can’t fix or modify software, open-source or not, it provides the same limitations as proprietary software.

Although it is open-source, Snap on the other hand, only works with the Ubuntu Store. Nobody knows how to make a Snap Store and nobody can. The Snap client is designed to work with only one source, following a protocol which isn’t open, and using only one authentication system. Snapd is nothing on its own, it can only work with the Ubuntu Store.

At work, I cannot maintain this project. At home, I'd rather spend time with my children and on projects that I'm currently passionate about.

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

Augmented Steam is an open source project. You can verify the code for yourself, help us improve it or create your very own version.

👍 Upvote issue #204 if you want to see it land faster.

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.

Open source is fundamentally good with the transparency and flexibility it brings; however, as our reliance on it goes up, the overall investment back into the ecosystem has not. It can be easy to take for granted the time and effort many developers put into open source projects. Yet it is with their time and effort that we often save our own.

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.

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.

Chromium is a very popular web browser, the fully open source counterpart to Google Chrome.

I don’t think he implies that, he didn’t mentioned FOSS or non-FOSS. Third party doesn’t refer to licensing, only to who provides it.

wouldn’t that « lesser » the FOSS effort towards desktop app’s ?

Snap gets rid of dependency mess. Good. Snap offers in one place FOSS and proprietary app’s. Here I am suspicious. It may be an advantage for a commercial app-store and for some users. But this advantage may lead to loss of comfort and flexibility for the many users that rely first on FOSS.

If it is powerful and reliable, that means it serves them better.

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.

Following the model of open-source software, we can enter our ideas and expressions into public discourse

Our team is building open source community tools and Svelte fits our identity as an independent labor of love with an organic community.

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.

Better community building: At the moment, MDN content edits are published instantly, and then reverted if they are not suitable. This is really bad for community relations. With a PR model, we can review edits and provide feedback, actually having conversations with contributors, building relationships with them, and helping them learn.

There are actually 3 other libraries that implements material in svelte, i hope this to become the community favorite because using MDC underneath it implements correctly Material guidelines.

If you are a developer and would like to fork, modify and/or contribute to this extesion, then this section is for you.

It is open to the community to help set its direction.

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.

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)

So I propose having the repo in place, and using it for targeted proposals where we really want feedback from early users, and hold off formalising anything more until early next year, as you said.

Express - 19 $ 🏃‍♀️ Skip the Review Queue 🕒 Published in 3 days 💌 Full Customer Support 💚 Support the team

Tunnelgram is fully open source (server and client) and uses the Tunnelwire Encryption Scheme, so you can see all of the code it's built on.

As a result, it is no longer open source.

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?

Over time Adam, Surplus' creator, had less and less time to spend on the project and I decided to take my own shot.

But maybe this PR should still be merged until he finds time for that?

Sorry this sat for so long!

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

Open Source flutter Apps permits you to make lovely native apps on iOS and Android from one codebase. The most goal of this repository is to seek out free open supply apps and begin contributive. Be at liberty to contribute to the list, any suggestions square measure welcome!

Stallman has also stated that considering the practical advantages of free software is like considering the practical advantages of not being handcuffed, in that it is not necessary for an individual to consider practical reasons in order to realize that being handcuffed is undesirable in itself.

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.

How does the licensing work in this new setup? Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.