It is hard for me to plan so far ahead, but I will mark the spot to get the reminder.
In UTC+3 it will be 22:00 Jan 6th, 2021 - 
I donât live alone, so I wonât be able to speak loud, unless I find some friendly place for people with notebooks.
1 Like
Thanks, Anatoli. In that case, letâs schedule that as the date! Iâll send out notes soon.
@rpekrul, thanks for those words. Looking forward to seeing what this group wants to do and what direction we can take these conversations.
1 Like
@RichardLitt thanks for facilitation. )
@rpekrul here is my wishlist in advance, to save some time and get thoughts in order. )
There are technical problems with detecting dependencies. To me these are all solvable. Starting a blog that describes each problem and giving a codegolf or exorcism challenge for it, sounds rather fun. So a little help with increasing visibility of problems with detecting dependencies will make it. The problem right now is that even problems with trivial missing things (like API for reading requirements.txt in Python) are not visible. It is just one small issue among thousands on Python trackers. Actionable blog is the one that starts with user story or a use case, and which can be referenced without a paywall. Separate category are the stories about non-solvable problems in dependency resolution. These just need diagrams with names that could be remembered. Names that could be used by people to quickly share and communicate the context in which such issues occur. Iâve seen some posts about advanced dependency solvers with a lot of text and no diagrams, and this is disappointing. Investing more time into teaching people how to do viz tools for those problems is also a worthy investment. Maybe it will stop proliferation of package formats⊠because dependency solver is the tombstone of any packaging.
There are also sustainability problems in dependency mapping. For me these are about people, and my interest is not replacing people with other people. I feel sad about being replaced by someone else, being unable to maintain my packages, and this is a problem I am trying to solve. My crisis is a financial and existential one. I want to support the work I am doing without revealing my identity, without corporate terror on the code in public repos. I want to use my nickname for communication and feel financially safe if the code that occupies a valuable portion of my semi-persistent brain cell memory, is of any value to the outside world. I am not really comfortable surviving in the market economics, which was never useful for supporting any infrastructure, from civil to research.
@abitrolly Thanks! Would it be possible to clarify a few points below? Itâs helpful to document these.
Would you mind expanding on this?
I am particularly interested this from a FairOSS perspective, would you mind sharing more?
Can you expand on the concept of financially safe?
Thanks again!
1 Like
I bet everybody have seen this strip from xkcd: Standards
I start with general development process, and then boil it down to packaging problem. I can not speak of reasons for everybody, but I reinvent things when I get the feeling that existing standard or packaging is complicated, flawed, doesnât work, or rather when I donât understand why it doesnât do what I want. At start I may have a feeling that I know how it should be done, and with time matters become complicated, I hit Norris wall more often, pressure leaves me less time to weight my decisions or document them, hacks, bugs and unvalidated PRs start to creep into the tiny nifty peaceful codebase that is stored in my mind. Non solvable problems start to haunt me, and I can not even document them, because again, I may not completely understand the causes, or how to fix them. Like some hack gained so much adoption that removing it will break so many things for many people. Or some popular format is so widespread, that my software becomes a mess of workarounds that is hard to make a sense of. After spending three or four week banging against a problem with no result, there is less and less motivation to get back to it. Some PRs can become lingering for ages. Especially when one has a job to do.
For packaging the ultimate problem is the dependency solving. It is a lot of fun to invent your own format from scratch, get files into it, metadata out of it, build package discovery and install/uninstall mechanism, but when it comes to detecting dependency conflicts, broken packages and installations, non-atomic upgrades - these are not the problems that one would think of when inventing software that packs files into archive. I havenât seen packaging standards that describe the algorithm to resolve version conflict. Most standards describe how things should work, not how to fix them. When people invent packaging, the least they expect is solving code dependency conflicts for their users. And if the versions of dependencies are incompatible, there is probably a good reason why it happens. For example, for one piece of software new version of dependency contains a fix that âbreaks everythingâ, and for other piece of the same software there is a critical function in that dependency. But for users, they try to pull this all together, the installation just breaks, and âpackaging doesnât workâ. These problems can not be fixed by reinventing packaging. They can be fixed by a lot of people collectively maintaining and patching source, like it happens with Linux distributive. So when packaging format is mature enough to reach these kind of problems - conflicts on the 2nd level of dependency resolution and deeper - they enter the problem space that can not be solved by just packaging format or nifty dependency solver. Even if you can patch your own code, then patching dependency of dependency is not possible. The thing of last resort in packaging is the dependency solver, and after it fails, people just start âvendoringâ or stuffing their dependencies into their codebase. Thatâs why I call the dependency solver a tombstone of packaging.
Well, letâs start with infrastructure we know. In my city, streets cleaning, water, electricity and other citizen services are provided by government. I mean around 50% of my earnings are taken away in the form of taxes. Market economics is all about supply and demand, and self-regulation, but where is it here? It is just taking the money from one group of people and distributing to others. If market economics is so effective, why there is no example of a city with good economics and clean streets? There are some counter examples, like New York, but Iâve never been there to tell.
My observation is that market economics works good on expansion on free resources, like oil, where you can seize the source, and then the game starts to trade limited supply and balance it with demand. That was before software appeared. People tried to restrain software copying with copyright, licenses, patents etc. Because they want the same revenue source. With the story of Aaron Swartz we still can see how this old world grasps for control over scientific publications. From economics view, these historically built systems feed many people, and they try to protect their âsalariesâ or âpensionâ or whatever by executing the force of law over any initiative to open access to research papers. The market economics fails to support the research infrastructure not only, because of limits to the research. Big companies we all know, like Sony who invented a whole lot of things in the past, stopped doing this, and financing more research. New western management probably calculated that it is ânot profitableâ for the companies to plan for 10 years ahead. Thatâs why research is funded by government.
Speaking of research funding, open source infrastructure is not covered by those funds. For example, Folding@Home project that fights COVID-19 has only one developer on the payroll, and people behind the project lack of cash to even hire professional fundraisers to help the under powered efforts of software maintenance. The hugely popular control software for this distributed computing initiative doesnât work out of the box on Fedora, because there is nobody available on the developers side to fix the shebang line. I started to ask for that on the project Discord, and thatâs how I know about the problem.
The market gameplay may work if well-being and traceability of the delivery chain becomes a new âcommodityâ. Like it happened with some well known clothing brands whoâve made their fortune by exploiting the cheap work force and poor work conditions in India. After the story went public after a fire at one factory where many people died, those companies stated to apologize in the media, and taking steps to improve their conditions. In the world of open source, we donât see when people die or something happens to them. We just see that maintainer becomes inactive. For clothing company the equivalent is that media just wonât publish the story.
For FairOSS mission, as it stated on the website right now âOur Mission is to sustain the production and maintenance of freely shareable intellectual property.â. One way to do this, is to replace âweak delivery chainâ with âstrongâ one. Like hiring an outsourcing corporation to take over the project, fork or rewrite it. From the market point it is probably not resource efficient to care about person, who had gone from the scene. Maybe he got terminally ill, maybe died, why the company need to spend resources on him? There are plenty of other solutions to the company problem. In the market economics it is fair to not care about other people, because companies survive when they have profits. The journalism helped to balance this system a bit, but because such journalism works against profits, the market finds a way to remove them. Making matters public is only one side of the problem of fairness.
The other side of the problem is I donât feel like it is fair for me to steal the attention from someone who is more talented than me. Even if I made some lib that became popular, there is a chance that somebody can just do a better work. What is my role in that then? As a loser in this game should I just step down and get back to market? And if I canât, is it just my personal problem, which doesnât relate to open source at all? I think no. The open source software is a promise that everybody can improve on that, that we can together bring better systems that allow to build greater things. The unfair thing is that in parallel to that activity we have to compete for food and resources. This is where I personally fail.
Being able to cover the average living cost in my city for few months ahead. I tried to make a public graphics of my expenses with separate balances (cards) for food and accomodation, but banks in Belarus do not provide any API for personal accounts, and donât want to collaborate to create one.
To expand on that, one card with public balance, that I can use to buy food, another where I can register spending on logistics and accommodation, and a third one for clothes and medicine. Food, clothes, shelter and medicine as basic necessities by some Buddhist teachings. That wonât be enough if I had children, so thatâs probably why I donât have them. Thatâs only my side of story from the leaf of some dependency tree. I donât know if other open source supporters have to face with such choices. Leaving all that stuff aside, financially safe also means I can travel to meet with my friends, go snowboarding and do stuff I used to in the past, do medical checkup once a year, including dentist and some specific cancer screening. I realize that many people in the world are living in much worse conditions, and thatâs also the sad part of the story about what is fair and what is not. But the concept of being financially safe is being able to take care of myself and having funds for that.
I feel like erasing the whole post be now, because I can not really answer the question. It is a heavy writing with a lot of emotional burden. I donât think that anyone ever would be comfortable with defining what is to be âfinancially safeâ for them. I bet everybody has dreams and inspirations and the hope to fulfill these dreams. Constraining oneself to the bare minimum of necessities is the same as knowing that you will never be able to reach those dreams. Throwing away oneâs dreams it is not an easy thing to live on.
I went ahead and started a Google doc before I forget during the holidays, you all should have comment to access to this file. I can change to edit access if needed but thought to keep things from being overwritten I would start with comment.
Look forward to the chat in January!
1 Like
According to my reminder, the meeting should start in 10 minutes, or did I set something wrong?
1 Like
Thanks everybody. That was inspiring. If we have a record, I would be interested to share it. )
Hey all, just wanted to see if people were open to meeting up again to talk through users, use cases, requirements for dependency scanning tools?
I know we met Wednesdays at 1pm CT last time. Is this a time that is pretty consistent for everyone? If so, @RichardLitt let me know if you want to schedule or I can. Hope everyone is doing well!
1 Like
I would be interested to discuss things, like technical side of Python dependency tracking and Sloan support for that, as well as an idea of a âDependency Tracking Cookbookâ with user stories, but I am not going to make it today.
1 Like
Thanks, Russell and @abitrolly! Iâm sorry for the delay in sending out the Doodle Poll before this week!
To ensure that 1pm CT works for everyone, and that we know availability, hereâs some times around that time which we can fill out in a poll. Thanks Rus for the reminder on this:
I love wednesdays and input my preferences into the Doodle, thanks Richard and Russ. Hope you can make it next week Anatoli!
1 Like
Note - this is for a recurring, biweekly meeting.
Hi all, created a doc for us to work from next week. Check it out here. Iâm pretty sure this is what we wanted to discuss but feel free to edit. Talk soon!
Iâm moving house next week so may need to skip but in general I am here for the conversation about a centralised dependency graphing/mapping/parsing service and the approaches that are available to us.
2 Likes
Wednesdat at 1:00pm EST seems to be the best time for everyone. Iâve sent everyone invites to the calendar event. If anyone else wants to be invited, please let me know!
Also, please add agenda items to the document Russ created above, if you could.
1 Like
I havenât got the invite. Can you send it to anatoli@rainforce.org ?
I suppose the meeting should be in half an hourâŠ