It makes a big difference to be working for yourself, rather than someone else. It shows that people are motivated by more than money. We have an intrinsic desire to create things.
I'm a creative. I have to create. I would be satisfied with nothing less.
I used to think, like you, that everyone was like me. But I've discovered, most are not. Most are happy to float through life just consuming what is around them.
Sure,many lack opportunities and resources. But creatives exist everywhere - creatives create regardless. There are lots of creatives, but most are just consumers.
It makes a big difference to be working for yourself, rather than someone else
Statements like this, and the whole article basically, make me wonder - since I'm apparently an outlier because none of this is really true for me - whether this originates from people doing jobs they don't really like and/or working for companies which have questionable work ethics and/or working for companies which are mostly about profit not product. I don't really feel any difference in motivation for the payed jobs I do and the contributions to OSS and the personal side projects. And to some extent: the hobbies I have, the non-software things I build. I just want to get creative and do the best thing possible. Sometimes that gets skewed somewhat due to certain requirements, and that happens more for payed jobs, but that doesn't change my motivation.
Today we treat work by a professional as being of higher standard than an amateur. A pro footballer clearly plays better than someone in an amateur league.
But it was not always so.
In recent history "professional" indicated that the task was bounded by time, and thus constrained in quality. An amateur building say a clock could take unbounded time, and hence create a superior product whereas a professional had to sell the clock, so it had to be produced in affordable time.
John Harrison starts life as a carpenter, making some clocks on the side as a hobby, interested more in perfecting the concept of clock than selling clocks for money. (although he had a prize in sight for inventing an accurate nautical clock.)
Despite making only a handful of clocks in his life, he's credited as being the most important clock maker ever.
Thus it is with OSS. Given the lack of monetary benefit, the benefits of writing it have to be elsewhere. In the satisfaction of a job done well. In the beauty and elegance of the code. The timeless perfection.
Or the idea that OSS presence will look good on your CV and held get you that job. In which case just throw stuff at Github to make a "portfolio". Never to be looked at again.
I think it's safe to say that the majority of OSS is the later, but we are all better off for the fraction that is the former.
As examples I would like to call out ffmpeg and x264. Years of refining and refining make it software of a quality that didn't exist before in the world of codecs.
I don't like the word "amateur" in this context - the semantic shift from its origins, and the baggage the word brings with it today makes it feel ... dismissive, insulting; easy to discount and ignore. Looking at the word's synonyms reinforces that feeling[1].
"Hobbyist", on the other hand, feels both knowledgeable and at the same time homely, unthreatening, to me (see synonyms[2]). I don't like talking about my JS library on GitHub[3] as a "side project" (a phrase I think many people would interpret as: "something that may one day make some good money"). Rather, I think about it as one of my hobbies, something I do because the work both fascinates and pleases me, allows me to experiment and push boundaries of what's possible to do with a 2d canvas element in the browser without the need to meet the demands and constraints of employers, clients, time, etc.
One of my other hobbies is writing poetry, which probably explains why I care too much about the meanings of words ...
A certain distance has opened up in modernity. It is between what is
accounted for and what is casual. Between the formal and the informal.
Official, and unofficial. It is about what it "recognised" ... by
whom?
Paradoxically, this age in which everything must be measured,
approved, certified and stamped, has made the amateur-professional
distinction more about the rituals and symbols of quality rather than
measurable quality.
My bachelors degree in CS&EE meant reading about 12 books, plus
validation through a gauntlet of examinations. For my troubles I got a
nice certificate and 40 years of salary increase. The reality is that
I read two dozen other books in my spare time as a teenager, just for
fun and interest, and received no degree for them. Since then I've
read many hundreds of books in my life, on philosophy, law,
psychology, politics and other subjects. No degrees.
Out of love, I've paid more attention, taken better notes and more
deeply considered those subjects than I did in the brief 3 years upon
which my credentialled career is predicated.
Interestingly a doctor, lawyer or professional politician [1] is as
free to write code on which a billion people depend as I, yet I cannot
practice law, treat patients or have much of a say in how my society
is run [2] - not that I'd be any good at those things.
Professionalism seems as much about money as it is about how society,
including its incumbent elites and class structures, select who is
"recognised", who gets to bestow the blessings, and ultimately to
control produce and behaviour.
While in the army many young lads, whose "heart isn't really in it",
are technically "professional soldiers". They hang up their boots
after the first tour. Only the crazy ones who become "contractors"
(mercenaries) might be said to have the truest instinct for it.
Software has carved out a very unusual niche this past 50 years. It's
a mercenary game, so complex and difficult that a genuine meritocracy
ensues, one that cannot be ignored or papered over with accolades or
associations. Either your code works or it doesn't.
But that unregulated laissez faire has also created a brutal world in
which becoming a "professional" coder is certainly the best way to
kill any fun and love for it. Meanwhile many well paid, hard working
lawyers and doctors hold on to the love for their work.
So I think "professionalism" and the identity, recognition, provision
and protections it can offer makes for some very interesting
distinctions.
[1] Should we even have "professional" politicians?
[2] Voting in a race between two idiots doesn't count.
>Paradoxically, this age in which everything must be measured, approved, certified and stamped, has made the amateur-professional distinction more about the rituals and symbols of quality rather than measurable quality.
I'm not sure about it. it's more about the behaviour you display. If you want a secure job it's better to display servitude and finish your degree even if you would make more progress on your own. When you want to become an artist or entrepreneur it is better to display a strong will, risk taking & inability for submission which sometimes means to drop out and follow your own thing.
I truly believe that if you want to get to the top you need to leave the path most people take with the risk to land at the very bottom.
> [...] so complex and difficult that a genuine meritocracy ensues, one that cannot be ignored or papered over with accolades or associations. Either your code works or it doesn't.
I don't think complexity automatically breeds meritocracy, and I don't think software is a meritocracy. There's still a "human side" of things that may drown out true merit.
For example my first OSS project went something like this: I wrote something from scratch with thousands of lines of code and put it out under the GPL. I told my friend about it. My friend forked the project, wrote only a handful of lines of code of his own, and did a better job at advertising his fork than I did on mine. The result was that he basically stole control over the OSS project from me by doing a better job as a marketer rather than as a programmer. ...nothing meritocratic about that.
One thing that has happened to me quite a lot working in commercial environments. Me: "Hey boss, I see your team is trying to tackle problem X with solution Y which doesn't take into account complexity Z. Let me solve that for you." Boss: "Okay, explain complexity Z to me." Me: "Yadda, yadda, yadda, ..." Boss: "I don't understand. It must be because you're a bad communicator." Me: "It may be because I'm smarter than you, and, as a corollary, you're dumber than I. Throw in some Dunning-Kruger effect." Boss: "I'm not dumb, you're dumb, and whenever I let you near any complex problem, you end up making me feel dumb. I don't like feeling that way. Go write some HTML, where I don't end up feeling that way as I go about micromanaging you."
> Meanwhile many well paid, hard working lawyers and doctors hold on to the love for their work.
They really don't. Professional work life, or, any field to which you enter to work for money, is as difficult as the other. Software is not an exception.
It has more to do with our current economic system (capitalism) trying to get the maximum profit out of everybody and overworking them than the specificities of any field.
Could you talk more about this? I mean, I don't think it makes one an aristocrat to be an independently motivated person who isn't living hand to mouth. But what do you think allowed more people to focus on unfettered hobbies in the past, and why would you say are fewer people able to do that today?
Yes but you don't have to be wealthy to not work. 42% of Americans aren't employed. Would you say they're all aristocrats? You don't even necessarily need a family member to support you either, if you're willing to couchsurf, backpack, and be creative in how you acquire food. Lifestyle anarchists do that for instance, so they can move out and focus on their passions.
I think most not-employed people fall into categories like these:
- People too young to be in employment.
- People too old to be in employment.
- People with illnesses or disabilities that make employment difficult or impossible.
- People who don't have skills that anyone wants to pay them for.
These people are not aristocrats, for sure, but most of them will not be highly effective working for love as opposed to working for money.
Also, being poor can be exhausting. Someone who isn't employed and isn't an aristocrat is likely to have a lot of their mental energy taken up with surviving, which again is likely to make them less able to do wonderful things working for love.
Important note: of course all the above is "most", "likely", etc.; there will be exceptions. Some school-age people are geniuses. Some retired people still have plenty of energy and focus. Some people have illnesses or disabilities that make ordinary jobs impossible but can still do great things if they can do the work on their own time and on their own terms. Some people have skills that others would pay them for if the others had any sense but for whatever reason don't sell themselves well. Etc., etc., etc. But, proportionally, there are going to be fewer people suited to create great things while not employed among that 42% than among the aristocrats of an earlier age. (Or of this age.)
Another important note: Of course the starving artist or writer is something of a cliche, so it was never all aristocrats who were creating great things outside the constraints of paid employment.
I believe they think about persons such as Tycho Brahe, William Thomson, 1st Baron Kelvin, street-named Lord Kelvin, or even John von Neumann, whose father, Neumann Miksa, received the "von" from emperor Franz Joseph.
There is a difference between being given an island by the king to build your own astronomical observatory in the 1600s [1] and knowing that you don't have to worry about food and shelter for the next few years because of your well-placed long-term investments. In this sense, the very few amateurs left today are the billionaires funding their own space agencies and whatever else they fancy.
Yes, not the same, Tycho Brahe, estimated to own 1% of the entire wealth of Denmark at the time, treated his workers as slaves [1], and even owned a slave as jester [2]. Today we have wages.
[1] "Gellius appears to have feared that Tycho wanted to keep him on Hven 'working like a slave.'", 1991, Victor E. Thoren, The Lord of Uraniborg. A Biography of Tycho Brahe, Cambridge University Press, p. 357
> In this sense, the very few amateurs left today are the billionaires funding their own space agencies and whatever else they fancy.
This is probably true if your amateur project is building a rocket to go to Mars, but not true for the vast majority of independently-pursued projects of art, craft, design and engineering.
So one example (which is fairly recent) is the split between rugby union and Rugby league (two codes of rugby, playing by slightly different rules). Rugby was initially played at the "public" schools (which are in fact private) in the UK, where supposedly rugby originated. As it became more popular clubs from working class cities started playing rugby as well. Because working class men (in contrast to the rich men at private schools) could not afford to spend time playing rugby instead of working, the clubs started paying their players.
As these working class clubs started to become increasingly successful, the governing rugby body which was dominated by the private schools insisted that players are amateurs. The conflict escalated to the working class clubs splitting of to form a different code of rugby (rugby league). The classism behind the split is still causes animosity behind the different supporters in the UK (it is less so in e.g. NZ were rugby was never a rich kids sport).
its a capitalist narrative that only the moneyed class could indulge infinite time in their hobbies discounting the 'irrational' urge of a person with a 'bolt from the blue' to see to its fruition inspite of their own personal 'ruin'.
>the benefits of writing it have to be elsewhere. In the satisfaction of a job done well. In the beauty and elegance of the code. The timeless perfection.
or, more realistically and less rose tintedly, people want to implement a functionality for their personal use case and hack together some code and libraries to get it done as quickly as possible
Then what would be the point in publishing it? Open source isn't just copying files to GitHub. If you aren't putting yourself out there and helping others understand how they might benefit from your work, then it's like a tree falling in the forest. Evangelizing is probably the bulk of the effort. So who would risk embarrassing themselves by evangelizing a giant hairball they slapped together? Any open source of note, you can always count on the fact that someone poured their heart and soul into it, at some point in the project's lifecycle.
Uhm, I've worked on both free software projects that were "a giant hairball" and on nicely structured things to be proud of.
Whoever has ever done something knows that you can help someone more with a messy project that does something than a near-perfect codebase that does nothing of value. And you publish something to help someone else!
A personal project can be done to achieve something or to aim for that illusive perfection we can never achieve at work (or both, ofc: it's not a XOR). Neither is to be discounted!
Yes but without vision, elegance, and leadership, open source is just a dumpster for corporations. Sure dumps are very helpful. But it's still a dump. There's no reason why it has to be that way. For example, something like Goodwill that's helpful and pleasant at the same time.
The (modern?) association of "professional" and "quality" (aka "higher standard" as you describe it) has to do with this simple question: Are you willing to part with your money for something?
Being a professional implies that you will deliver a minimum standard of quality and consistency to your customers, because you as a professional are demanding money for your work. Amateur work by comparison can be all over the place, ranging from the mindblowing to the putrid, with no guarantees.
The flipside of this is that the only qualification to be a professional is whether you make money with your work. No matter how skilled or knowledgable you are, you aren't a professional if you can't successfully demand or aren't demanding money for your work.
> ..The only qualification to be a professional is whether you make money with your work.
So true. And professionals can range from "mindblowing to the putrid, with no guarantees" too. In fact, I'd say they are able to achieve a far greater level of putrid than non-professionals, "amateurs".
> An amateur is generally considered a person who pursues an avocation independent from their source of income. Amateurs and their pursuits are also described as popular, informal, self-taught, user-generated, DIY, and hobbyist.
That does describe much of the open source world.
But great work has come from amateurs. Ah, Wikipedia has a wonderful description of this.
> Contribution of amateurs
> Many amateurs make valuable contributions in the field of computer programming through the open source movement.
> Amateur dramatics is the performance of plays or musical theater, often to high standards, but lacking the budgets of professional West End or Broadway performances.
> Astronomy, chemistry, history, linguistics, and the natural sciences are among the fields that have benefited from the activities of amateurs. Gregor Mendel was an amateur scientist who never held a position in his field of study. Radio astronomy was founded by Grote Reber, an amateur radio operator. Radio itself was greatly advanced by Guglielmo Marconi, a young Italian gentleman who started out by tinkering with a coherer and a spark coil as an amateur electrician. Pierre de Fermat was a highly influential mathematician whose primary vocation was law.
> In the 2000s and 2010s, the distinction between amateur and professional has become increasingly blurred, especially in areas such as computer programming, music and astronomy. The term amateur professionalism, or pro-am, is used to describe these activities.
The fact that other people are willing to pay money for a professional's work is a social signal that the work meets at least a minimum standard of quality or fitness to purpose.
> the only qualification to be a professional is whether you make money with your work
Which, on top of the aforementioned resources limitation, means client agency and a lots of time spent marketing and selling... Many amateurs are experts who just don't want to deal with the commercial relationship.
This hasn't been the case since the 90s (though the move towards allowing them started much earlier). Professional athletes are allowed to compete in all sports these days. IIRC boxing was the last sport to hold on to the "amateurs only" rule but abandoned it for the 2016 olympics.
> Thus it is with OSS. Given the lack of monetary benefit, the benefits of writing it have to be elsewhere. In the satisfaction of a job done well. In the beauty and elegance of the code. The timeless perfection.
> Or the idea that OSS presence will look good on your CV and held get you that job. In which case just throw stuff at Github to make a "portfolio". Never to be looked at again.
> I think it's safe to say that the majority of OSS is the later, but we are all better off for the fraction that is the former.
In my case, it's the former, but the latter happens to be a byproduct.
The analogy that I use, when someone asks me why I do what I do, is thus:
Think of me as the old Swiss geek, making cuckoo clocks in his basement.
I like making cuckoo clocks. Like, a lot.
Cuckoo clocks aren't everyone's cup of tea, and that's fine with me. They are my cup of tea, and that's what matters to me.
It's my goal to make the best damn cuckoo clocks available. I hang them all over my house. Every hour on the hour sounds like a Munich Beer Hall band.
If you want a cuckoo clock, I'm your man.
If you don't, that's fine. I don't lose any sleep over it.
For art, no. But open source software does have the other side, so some inputs can be valuable and sometimes inspiring. I would compare it to industrial design.
Interesting note: the word amateur comes from the Latin Amat, to love. An amateur does what they do for their love - of music, art, programming or whatever, not for mundane reasons such as career, fame, or material compensation.
I don't think the gap between an amateur and an artist or business owner is the love for their work.
The gap is the ability to generate something of value to others to the point at which you can sustain your efforts without needing to subsidise it like a hobby.
The main problem is that people want to work for themselves and not for the nth horrible manager in a company they don't care about.
OSS is seen as a way to escape the rat race, either as a better job or as some form of passive income.
It's no wonder developers complain about not paying "customers", their goal was money from the get go.
This is why OSS can't be a replacement for paid software and companies should rely more on paid software - whether open or closed; paying money, after all, is nothing but a way to recognise the value that went into a piece of work.
OSS relies on a few exceptional individuals (Salvatore certainly being one of the enlightened ones - as well as someone that found a way to monetize) but it doesn't scale to your average Joe.
Except projects like Blender, Grafana, and others like it started small and became big. Building something commercially successful is an additional step, it's optional, but totally doable. There are distros and open source apps/games that charge on stores, which have developed a commercial component. Paying for work is a good thing to be doing.
blender started as a non-free commercial effort, that went bankrupt and had its source freed through a crowdfunding effort. as far as i can tell, it remains largely community funded.
grafana did start small and managed to raise funding from investors.
i think the blender model is the best future for FOSS though. funded by its users without making a profit. grafana's success is nice, but like most startups fail, that kind of success is not common.
I think there's money left on the table in both cases. Community funding will hopefully grow as users grow and the value grows, a reinforcing cycle, though projects might take time to get there I think. Projects like firejail could do commercial work, but don't.
there most definitely is money left on the table, but with any community led project, one has to be very careful with how such money is used. some people take non-profit very seriously, and don't want to contribute to a project that is using funds to pay some of their developers when others work for free.
that happened to debian. when they attempted to use some of their funds to hire developers some people got very upset.
so taking advantage of opportunities to earn money has to be carefully considered. the funds are best used for things that the community has been unable to achieve. or at least a community consensus for how to spend the money should be there, lest anyone get the impression that someone is able to enrich themselves through the project.
i can't think of a concrete example right now, but i seem to remember some projects that have literally fallen apart over issues like these.
not every project is like that of course, and debian may be the extreme here. but for most projects where this is not an issue it is because this has been clear from the start, and the kind of people for whom it would be an issue self-selected to avoid contributing to these projects in the first place.
I guess they are saying that both bug reporters and open source maintainers care about software quality (generally excluding learning projects and research prototypes and the like).
No shit. I don't think anyone has ever disputed that.
In the open source world we generally say that users are not entitled to anything. They get what we feel like giving, because they are not paying us.
This is just as true in the corporate world. If your manager tells you to do X, and some random on twitter wants you to fix bug Y, you do X not Y. The random on twitter probably cares about software quality too. That has no bearing on you probably ignoring them.
I have a question for experienced/skilled FOSS maintainers.
Are there any good ways to convert those who comment/suggest into contributors? I feel like instead of simply dismissing suggestions with "you get what you paid for", there must be a better way to handle the situation. Or perhaps I'm too naive on the topic
this is really hard. i believe well meaning suggestions come from two types of people, those who don't know how to do it, and those who are to busy to do it themselves.
most of the time when i d̶r̶o̶p̶/contribute a suggestion as a user then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and contribute a patch.
and for those who don't know how, most likely the idea they had is more complex than they would be able to do as a first project, even if they were willing to learn. they are better off contributing in other areas that match their skill-level or enable them to learn. but how to motivate them to work on something that does not relate to their suggestion? maybe by arguing that if they help with those beginner tasks over there, then someone else can find the time to work on their idea, but it feels risky to make that kind of promise.
so i would rather focus on those who say they want to contribute something but don't know what because they feel they don't have the skill. those are hopefully motivated to learn. point them to issues that are suitable for people starting out.
and for anyone else: thank you for the suggestion. patches for this idea are welcome. (and optionally) feel free to ask for pointers how to get started.
> i believe well meaning suggestions come from two types of people, those who don't know how to do it, and those who are to busy to do it themselves.
That is true, but there are also other issues, such as:
- Knowing most of what to write, but possibly missing some part of the code that you might not know of, which is needed to implement this feature.
They might not accept the change, leading to further things below:
- Possibility of breaking the interface and making it not compatible, especially with future versions of the official program if there are bit fields, structures, enumerations, etc that need to be extended.
- Needing to maintain your own fork of the project.
- If making multiple patches, making them to not interfere with each other.
I had made a repository of unofficial patches of SQLite; currently only contains my own patch for non-Unicode, and list of links to a few others. However, later I should perhaps add also such things as documents about enumerations, etc. Depending what needs to be done, possibly forking it and breaking the interface might have some advantages (can avoid some problems with the existing interface), but also disadvantages (more complicated to maintain).
> most of the time when i drop a suggestion then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and produce a patch.
I had considered this, and I think that you can specify reasons for dropping a suggestion, as well as details of what might be needed even if it is accepted but not implemented yet. As an example, I had made this list:
0. It already has this feature, or this capability can be easily done by the existing features.
1. Yes, I will likely add it soon (and may be working on it already).
2. Yes, but it is not a high priority; it may be added later.
3. Yes, but more work will be needed before it is added.
4. Probably; more work will be needed, and/or design decisions must be made, before it is added.
5. Maybe, but I am unlikely to implement it by myself; if you provide a patch then it will likely be added.
6. Unlikely, but possible. More work will be needed, and I probably will not add it by myself but a patch may be acceptable.
7. No, I consider it to be a bad idea. You may make your own fork of the project if you want it, though.
8. No, it is out of the scope of the intended project. You may make your own fork of the project if you want it.
9. No, it is probably too complicated and not very helpful anyways.
10. No, it is probably impossible. Forking it probably won't help.
11. The request is completely impossible; in addition to being impossible, it might also be incoherent, incomprehensible, unethical, etc.
In the case of bug fixes, it is a bit different, e.g. if you cannot figure out what is wrong, or if you do know what is wrong but you do not know how to fix it, etc.
sorry, i slightly edited my text to clarify that i was talking from the user perspective and didn't mean to imply that i just drop/reject suggestions as a project owner. for that, your list of responses is very good.
I am a CS student, three years away from being a software engineer.
Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it.
Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
That demotivates me a little about starting simple bug fixing PRs for big projects.
Fwiw, dont be afraid to jump right in. Your patch might get rejected, but that happens to experienced people all the time too, and is no big deal.
PRs that get ignored is really demotivating. It can depend on which project a lot. If you're new to the project informally (and politely) chatting about your patch on project's irc/discord can help ensure you are not missing any social conventions.
first of all, don't give up. being ignored or overlooked is part of the FOSS experience. not every developer is available all the time, some only work during holidays or whenever the mood strikes them. some would prefer to ignore rather than reject someone, or (especially on popular projects) they may be so busy that they simply didn't see your submission.
when you fix a problem consider first of all, to do it for yourself. for your experience, or to solve a problem that you actually have.
fixing a problem and then finding out that it is already fixed, or that someone elses later fix was accepted ignoring yours, is also a common experience. there is nothing malicious about it. communication is just not perfect, and for some things, it may just be easier for the known and trusted developers to fix a problem themselves rather than to take the effort to review your contribution, even though taking care of your contribution would give them the opportunity to invite a new contributor. not every project has inviting new contributors on their radar.
my suggestion would be to look at projects that have an explicit policy of being welcoming to new contributors. they will either say on their site or in the documentation, or they have issues that are marked "good for beginners" "or good for a first contribution" or something similar.
work on such issues. join the community, their mailinglists, chat rooms, or whatever they use, and talk to other developers there. get to know the people, help other new contributors, make friends. later when one of your submissions is ignored or overlooked again, those new friends will be able to help you get attention to it. or they may know why it was ignored.
> I am a CS student, three years away from being a software engineer.
Three years away from having a degree. If you routinely do software engineering, you're a software engineering (possibly s/engineer/develop/ for a similar claim.)
> Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
You are a saint! I would _love_ for people to read through my code looking for bugs and oddities.
Just remember that some FOSS projects are coded well, while others are coded horrendously.
> I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it.
>
> Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
If you are considering writing a PR, get in touch with developers in a chatroom, or even over email, to coordinate this. They are likely to respond favorably to offers of PRs, and tell you things like "Don't do it now, we have a refactor coming up" or "base yourself off of this branch". And even if they say "not interested, don't bother" - you've still gotten useful information from them.
The internet is full of crazy people. "You get what you pay for" is usually used on people who are obnoxious and super entitled. Its not generally (at least in my experience) used on people who are making good faith suggestions. Its used on people who want you to be their personal slave. I generally have only ever used "you get what you pay for" or "i would be happy to provide a full refund" to extremely rude people, as a slightly more polite version of "fuck off".
People who make good faith suggestions can sometimes be converted, but you also have to respect that some people don't have the inclination or time but can still make good suggestions. Sort of similar to how on an internet forum most people are lurkers and that is ok. Good faith suggestions are really valuable to open source projects.
Linux was created to meed common needs. For scratching each others' backs and sharing costs and risks, similar to investing in 1/10 of 10 risky enterprises, rather than taking on the full cost of one.
Except that I'd say this applies to Linux as well. The main reason why so many commercial users of Linux leave their drivers closed source is because they don't meet the quality requirements to push them upstream. Commercial work is typically done on project bases, you write the drivers once and that's the end of your job. That's not the case for Linux. Someone has to maintain the drivers, so you want the code to be maintainable. If you maintain something long term, you have to care about the quality.
Almost all popular open-source software has paying patrons – companies/universities that give time to the individual to work on that open-source project while keeping them gainfully employed.
In recent memory I cannot think of any serious open-source software that doesn't have individuals from well-paying tech companies contributing to it in significant ways. These projects are usually of higher quality and are done in the spirit of the open-source ethos - everything is done in the open with open governance etc. Usually expectation is everyone contributes and gets a lot of value for a lot less effort due to the collective effort.
Then, there's a long tail of unpaid software that's put out in GitHub etc. whose quality is highly suspect. They are done as a hobby of an individual, may not even have a proper project community structure (website, mailing list, seeking contributors etc).
Then, there's another category of open-source – these are commercial ventures that want to garner the goodwill associated with open-source model/movement to further the adoption of their commercial offering. Nothing wrong with it, as long as they are honest about it. They are different in some fundamental ways. They intend to control the fate of the project very tightly and privately and there is no open governance of the project. Entirety of the project may not be open-source. Big chunks of the critical functionality may be closed source. At some point they may change the open-source license of the project to make it more onerous.
Some of the best open-source software that I have seen that do both open-source and commercial parts really really well are sqlite, haproxy, nginx.
> Almost all popular open-source software has paying patrons
Because they are popular, people pay and contribute to popular things. Many become popular before they have paying patrons, but once you are popular you will get people who are happy to help pay and contribute.
> Almost all popular open-source software has paying patrons – companies/universities that give time to the individual to work on that open-source project while keeping them gainfully employed.
Surely, it's the other way around. You are likely thinking on projects which are not just popular, but with a target audience so large that they are nearly-mainstream-media-level popular, or alternative, important enough to be necessary for large corporations' activities. For those you may be right, and even there I'm not sure.
> In recent memory I cannot think of any serious open-source software that doesn't have individuals from well-paying tech companies contributing to it in significant ways.
Bash? Chet Ramey is employed at a university, but I don't think they pay him to work on it.
I agree with it that when the OSS is in the early stages. When the OSS has a large number of users, forms a community, and has commercial potential, things will change.
I like this a lot -- I think one take-away that isn't explicitly mentioned (that I, as a bit of a GNOME/Wayland hater get a lot) is that "you're not paying for it so you must not discourage what they are doing" is a pretty bad argument I hear frequently.
Even if you're Free and Open Source, you're injecting code and ideas into a community. By making that public (and intended for wide use) you are opening up for criticism from anybody to say "I think your software is bad and you should stop promoting it." That's just free speech 101.
the primary issue is in what tone the message is sent. i consider it reasonable to expect polite and friendly interaction. freedom of speech does not give anyone the right to hurt someones feelings.
if the software is bad, don't use it. if it is dangerous (you could loose work when you use it) then be explicit about the danger. "your software is bad" is a rather useless criticism. tell me why. tell me which alternative is better. tell me what would make my software better. but don't just tell me to stop promoting it, because that is not your place to say.
But, here's the thing in my experience. I might believe believe your software is "bad to the point of harming the ecosystem" (which I do feel about e.g. Wayland, I think they haven't done a good enough job of preserving backward-compatibility, YMMV)
At this stage, it is absolutely my place to say. And very frequently what happens is they put up arguments like yours, even when I have been explicit about the danger, which I do good-faith believe is real enough to get very critical about.
And very frequently what happens is they put up arguments like yours, even when I have been explicit about the danger
that is the challenge in every human interaction. sometimes it is difficult to tell how a message comes across. if it isn't well received, the best one can do is to back up, apologize that the message didn't come across the way it was meant to and try restating the problem in a different way.
and if that doesn't work, keep trying or give up. some people are just not open to any form of criticism, and the best one can do is to try to be polite and state the problem in neutral terms to anyone who needs to hear it.
That's one way to look at it, but mostly not mine.
Places like this; I don't argue with individuals primarily to privately change their minds. I argue "in public" to get the debate out there and perhaps change the minds of the other readers.
taking offense is almost always unwarranted. the point of an apology is not to admit that taking offense would be warranted but make clear that no offense was intended hoping to be able to continue the conversation.
i like to go by this: try to avoid offending anyone with what i say, but also try to not get offended by what others say.
if someone is offended, it could be something that was a trigger, or some misunderstanding, or that person is just to easily offended or there is some deeper issue that i am not aware of.
either way, there is a failure in communication, and if i want to continue the conversation, i need to find away around it. in most cases an apology is a way to do that. not doing anything about the offense assumes that the other person knows that their taking offense is unwarranted. but i believe many don't, or they wouldn't have taken offense.
if the person is reasonable, they will accept the apology and be able to calm down and the discussion can continue. if they are not, the conversation is most likely over, or it escalates. both are things i'd rather avoid.
Somewhat related; the Po/architect/techlead ( transcends titles) dude on my team , who is a great guy technically and team wise, is completely unmanageable when it comes to day work. Whichever issues he is assigned to he will not do... instead he will do some other stuff none ever though of or asked for (good stuff tho but won't see value or impact until at least half a year later), but if you assign a crystal ball gazing task to him he won't do that either, hell do something that should have been done 6 months ago. Management really got into work tracking ... So it's a constant cat and mouse game. He just wants to cash a check and do whatever he wants to do.
If I was painting a picture, and some well-meaning observer came up to me and said "I think the bottom left corner should be red; I want to hang a copy of this on my wall and it needs to co-ordinate with my colour scheme" then I would rightly tell them to go away and paint their own picture, or pay me to paint the picture they want.
Code is no different: you only get to tell me how my code should look and feel, or what features it has, if you pay me for it. If I'm creating it for the joy of creating it, then I get to say what it is and what it does. And it's utterly my right to refuse your money, block your comments, and continue doing something with my code that you don't like.
At least in OS you can fork my repo. Then it's your code and you can do what you like with it.
> The paradox is that the OSS writer cares and is often willing to fix code she writes for free, more than the other paid work she does.
I feel like the paradox of this claim is that paid work seems to be collectively far higher quality software than personal OSS projects. This claim is my opinion, I’m not stating it as fact, and I can certainly think of specific cases of very high quality OSS and very low quality commercial software. That said, in my experience both personal and witnessing others, the sum total open source software has a worse user experience precisely because it’s not catering to what other people need, while paid work might seem less cared for but actually does take care of all the boring chores that need to be done to make software great. Things like good documentation, good unit and end-to-end tests, and polished interfaces, just to name a few. Even just building a GUI is probably eschewed more often by OSS projects because it takes loads more work than making a functional CLI. All these things tend to get skipped more often when you’re writing software for yourself, it certainly has been true for me as well as other people I know. It certainly seems true if you pick random projects to read through on github or npm or whatever, most of it seems like it was a passion project for a month or so before getting abandoned.
> It's striking how often programmers manage to hit all eight points by accident. Someone has an idea for a new project, but because it's not officially sanctioned, he has to do it in off hours—which turn out to be more productive because there are no distractions.
> ordinary programmers working in typical office conditions never really understand the problems they're solving
Another key reason to me that open source can be very good quality is when the developer is the key user.
If the developer has strong knowledge of the business while designing a product, it always ends up with better qa as they are writing the right product on first draft.
You hardly get that when you hire someone to do something for you. That is valid in other domain than programming.
89 comments
[ 2.9 ms ] story [ 162 ms ] threadI'm a creative. I have to create. I would be satisfied with nothing less.
I used to think, like you, that everyone was like me. But I've discovered, most are not. Most are happy to float through life just consuming what is around them.
Sure,many lack opportunities and resources. But creatives exist everywhere - creatives create regardless. There are lots of creatives, but most are just consumers.
And that's fine.
Statements like this, and the whole article basically, make me wonder - since I'm apparently an outlier because none of this is really true for me - whether this originates from people doing jobs they don't really like and/or working for companies which have questionable work ethics and/or working for companies which are mostly about profit not product. I don't really feel any difference in motivation for the payed jobs I do and the contributions to OSS and the personal side projects. And to some extent: the hobbies I have, the non-software things I build. I just want to get creative and do the best thing possible. Sometimes that gets skewed somewhat due to certain requirements, and that happens more for payed jobs, but that doesn't change my motivation.
But it was not always so.
In recent history "professional" indicated that the task was bounded by time, and thus constrained in quality. An amateur building say a clock could take unbounded time, and hence create a superior product whereas a professional had to sell the clock, so it had to be produced in affordable time.
John Harrison starts life as a carpenter, making some clocks on the side as a hobby, interested more in perfecting the concept of clock than selling clocks for money. (although he had a prize in sight for inventing an accurate nautical clock.)
Despite making only a handful of clocks in his life, he's credited as being the most important clock maker ever.
Thus it is with OSS. Given the lack of monetary benefit, the benefits of writing it have to be elsewhere. In the satisfaction of a job done well. In the beauty and elegance of the code. The timeless perfection.
Or the idea that OSS presence will look good on your CV and held get you that job. In which case just throw stuff at Github to make a "portfolio". Never to be looked at again.
I think it's safe to say that the majority of OSS is the later, but we are all better off for the fraction that is the former.
As examples I would like to call out ffmpeg and x264. Years of refining and refining make it software of a quality that didn't exist before in the world of codecs.
"Hobbyist", on the other hand, feels both knowledgeable and at the same time homely, unthreatening, to me (see synonyms[2]). I don't like talking about my JS library on GitHub[3] as a "side project" (a phrase I think many people would interpret as: "something that may one day make some good money"). Rather, I think about it as one of my hobbies, something I do because the work both fascinates and pleases me, allows me to experiment and push boundaries of what's possible to do with a 2d canvas element in the browser without the need to meet the demands and constraints of employers, clients, time, etc.
One of my other hobbies is writing poetry, which probably explains why I care too much about the meanings of words ...
[1] - https://www.thesaurus.com/browse/amateur
[2] - https://www.thesaurus.com/browse/hobbyist
[3] - https://github.com/KaliedaRik/Scrawl-canvas
A certain distance has opened up in modernity. It is between what is accounted for and what is casual. Between the formal and the informal. Official, and unofficial. It is about what it "recognised" ... by whom?
Paradoxically, this age in which everything must be measured, approved, certified and stamped, has made the amateur-professional distinction more about the rituals and symbols of quality rather than measurable quality.
My bachelors degree in CS&EE meant reading about 12 books, plus validation through a gauntlet of examinations. For my troubles I got a nice certificate and 40 years of salary increase. The reality is that I read two dozen other books in my spare time as a teenager, just for fun and interest, and received no degree for them. Since then I've read many hundreds of books in my life, on philosophy, law, psychology, politics and other subjects. No degrees.
Out of love, I've paid more attention, taken better notes and more deeply considered those subjects than I did in the brief 3 years upon which my credentialled career is predicated.
Interestingly a doctor, lawyer or professional politician [1] is as free to write code on which a billion people depend as I, yet I cannot practice law, treat patients or have much of a say in how my society is run [2] - not that I'd be any good at those things.
Professionalism seems as much about money as it is about how society, including its incumbent elites and class structures, select who is "recognised", who gets to bestow the blessings, and ultimately to control produce and behaviour.
While in the army many young lads, whose "heart isn't really in it", are technically "professional soldiers". They hang up their boots after the first tour. Only the crazy ones who become "contractors" (mercenaries) might be said to have the truest instinct for it.
Software has carved out a very unusual niche this past 50 years. It's a mercenary game, so complex and difficult that a genuine meritocracy ensues, one that cannot be ignored or papered over with accolades or associations. Either your code works or it doesn't.
But that unregulated laissez faire has also created a brutal world in which becoming a "professional" coder is certainly the best way to kill any fun and love for it. Meanwhile many well paid, hard working lawyers and doctors hold on to the love for their work.
So I think "professionalism" and the identity, recognition, provision and protections it can offer makes for some very interesting distinctions.
[1] Should we even have "professional" politicians?
[2] Voting in a race between two idiots doesn't count.
I'm not sure about it. it's more about the behaviour you display. If you want a secure job it's better to display servitude and finish your degree even if you would make more progress on your own. When you want to become an artist or entrepreneur it is better to display a strong will, risk taking & inability for submission which sometimes means to drop out and follow your own thing.
I truly believe that if you want to get to the top you need to leave the path most people take with the risk to land at the very bottom.
I don't think complexity automatically breeds meritocracy, and I don't think software is a meritocracy. There's still a "human side" of things that may drown out true merit.
For example my first OSS project went something like this: I wrote something from scratch with thousands of lines of code and put it out under the GPL. I told my friend about it. My friend forked the project, wrote only a handful of lines of code of his own, and did a better job at advertising his fork than I did on mine. The result was that he basically stole control over the OSS project from me by doing a better job as a marketer rather than as a programmer. ...nothing meritocratic about that.
One thing that has happened to me quite a lot working in commercial environments. Me: "Hey boss, I see your team is trying to tackle problem X with solution Y which doesn't take into account complexity Z. Let me solve that for you." Boss: "Okay, explain complexity Z to me." Me: "Yadda, yadda, yadda, ..." Boss: "I don't understand. It must be because you're a bad communicator." Me: "It may be because I'm smarter than you, and, as a corollary, you're dumber than I. Throw in some Dunning-Kruger effect." Boss: "I'm not dumb, you're dumb, and whenever I let you near any complex problem, you end up making me feel dumb. I don't like feeling that way. Go write some HTML, where I don't end up feeling that way as I go about micromanaging you."
They really don't. Professional work life, or, any field to which you enter to work for money, is as difficult as the other. Software is not an exception.
It has more to do with our current economic system (capitalism) trying to get the maximum profit out of everybody and overworking them than the specificities of any field.
In modern times it is usually assumed that an amartur has a real job and can only devote so much time to their hobbies.
- People too young to be in employment.
- People too old to be in employment.
- People with illnesses or disabilities that make employment difficult or impossible.
- People who don't have skills that anyone wants to pay them for.
These people are not aristocrats, for sure, but most of them will not be highly effective working for love as opposed to working for money.
Also, being poor can be exhausting. Someone who isn't employed and isn't an aristocrat is likely to have a lot of their mental energy taken up with surviving, which again is likely to make them less able to do wonderful things working for love.
Important note: of course all the above is "most", "likely", etc.; there will be exceptions. Some school-age people are geniuses. Some retired people still have plenty of energy and focus. Some people have illnesses or disabilities that make ordinary jobs impossible but can still do great things if they can do the work on their own time and on their own terms. Some people have skills that others would pay them for if the others had any sense but for whatever reason don't sell themselves well. Etc., etc., etc. But, proportionally, there are going to be fewer people suited to create great things while not employed among that 42% than among the aristocrats of an earlier age. (Or of this age.)
Another important note: Of course the starving artist or writer is something of a cliche, so it was never all aristocrats who were creating great things outside the constraints of paid employment.
- People who are doing unpaid care work (e.g. for children, or sick relatives)
There is a difference between being given an island by the king to build your own astronomical observatory in the 1600s [1] and knowing that you don't have to worry about food and shelter for the next few years because of your well-placed long-term investments. In this sense, the very few amateurs left today are the billionaires funding their own space agencies and whatever else they fancy.
[1] https://en.wikipedia.org/wiki/Tycho_Brahe#:~:text=King%20Fre...
[1] "Gellius appears to have feared that Tycho wanted to keep him on Hven 'working like a slave.'", 1991, Victor E. Thoren, The Lord of Uraniborg. A Biography of Tycho Brahe, Cambridge University Press, p. 357
[2] ibid., p. 193
This is probably true if your amateur project is building a rocket to go to Mars, but not true for the vast majority of independently-pursued projects of art, craft, design and engineering.
As these working class clubs started to become increasingly successful, the governing rugby body which was dominated by the private schools insisted that players are amateurs. The conflict escalated to the working class clubs splitting of to form a different code of rugby (rugby league). The classism behind the split is still causes animosity behind the different supporters in the UK (it is less so in e.g. NZ were rugby was never a rich kids sport).
You can read more here https://www.newstatesman.com/culture/sport/2019/10/split-bet...
or, more realistically and less rose tintedly, people want to implement a functionality for their personal use case and hack together some code and libraries to get it done as quickly as possible
Whoever has ever done something knows that you can help someone more with a messy project that does something than a near-perfect codebase that does nothing of value. And you publish something to help someone else!
A personal project can be done to achieve something or to aim for that illusive perfection we can never achieve at work (or both, ofc: it's not a XOR). Neither is to be discounted!
Being a professional implies that you will deliver a minimum standard of quality and consistency to your customers, because you as a professional are demanding money for your work. Amateur work by comparison can be all over the place, ranging from the mindblowing to the putrid, with no guarantees.
The flipside of this is that the only qualification to be a professional is whether you make money with your work. No matter how skilled or knowledgable you are, you aren't a professional if you can't successfully demand or aren't demanding money for your work.
So true. And professionals can range from "mindblowing to the putrid, with no guarantees" too. In fact, I'd say they are able to achieve a far greater level of putrid than non-professionals, "amateurs".
> An amateur is generally considered a person who pursues an avocation independent from their source of income. Amateurs and their pursuits are also described as popular, informal, self-taught, user-generated, DIY, and hobbyist.
That does describe much of the open source world.
But great work has come from amateurs. Ah, Wikipedia has a wonderful description of this.
> Contribution of amateurs
> Many amateurs make valuable contributions in the field of computer programming through the open source movement.
> Amateur dramatics is the performance of plays or musical theater, often to high standards, but lacking the budgets of professional West End or Broadway performances.
> Astronomy, chemistry, history, linguistics, and the natural sciences are among the fields that have benefited from the activities of amateurs. Gregor Mendel was an amateur scientist who never held a position in his field of study. Radio astronomy was founded by Grote Reber, an amateur radio operator. Radio itself was greatly advanced by Guglielmo Marconi, a young Italian gentleman who started out by tinkering with a coherer and a spark coil as an amateur electrician. Pierre de Fermat was a highly influential mathematician whose primary vocation was law.
> In the 2000s and 2010s, the distinction between amateur and professional has become increasingly blurred, especially in areas such as computer programming, music and astronomy. The term amateur professionalism, or pro-am, is used to describe these activities.
Which, on top of the aforementioned resources limitation, means client agency and a lots of time spent marketing and selling... Many amateurs are experts who just don't want to deal with the commercial relationship.
> Or the idea that OSS presence will look good on your CV and held get you that job. In which case just throw stuff at Github to make a "portfolio". Never to be looked at again.
> I think it's safe to say that the majority of OSS is the later, but we are all better off for the fraction that is the former.
In my case, it's the former, but the latter happens to be a byproduct.
The analogy that I use, when someone asks me why I do what I do, is thus:
Think of me as the old Swiss geek, making cuckoo clocks in his basement.
I like making cuckoo clocks. Like, a lot.
Cuckoo clocks aren't everyone's cup of tea, and that's fine with me. They are my cup of tea, and that's what matters to me.
It's my goal to make the best damn cuckoo clocks available. I hang them all over my house. Every hour on the hour sounds like a Munich Beer Hall band.
If you want a cuckoo clock, I'm your man.
If you don't, that's fine. I don't lose any sleep over it.
I didn't have to develop a new computer music for a musicology phd and my scholarship was just for a humanity thesis, but I just wanted to do it.
The gap is the ability to generate something of value to others to the point at which you can sustain your efforts without needing to subsidise it like a hobby.
OSS is seen as a way to escape the rat race, either as a better job or as some form of passive income.
It's no wonder developers complain about not paying "customers", their goal was money from the get go.
This is why OSS can't be a replacement for paid software and companies should rely more on paid software - whether open or closed; paying money, after all, is nothing but a way to recognise the value that went into a piece of work.
OSS relies on a few exceptional individuals (Salvatore certainly being one of the enlightened ones - as well as someone that found a way to monetize) but it doesn't scale to your average Joe.
grafana did start small and managed to raise funding from investors.
i think the blender model is the best future for FOSS though. funded by its users without making a profit. grafana's success is nice, but like most startups fail, that kind of success is not common.
that happened to debian. when they attempted to use some of their funds to hire developers some people got very upset.
so taking advantage of opportunities to earn money has to be carefully considered. the funds are best used for things that the community has been unable to achieve. or at least a community consensus for how to spend the money should be there, lest anyone get the impression that someone is able to enrich themselves through the project.
i can't think of a concrete example right now, but i seem to remember some projects that have literally fallen apart over issues like these.
not every project is like that of course, and debian may be the extreme here. but for most projects where this is not an issue it is because this has been clear from the start, and the kind of people for whom it would be an issue self-selected to avoid contributing to these projects in the first place.
I guess they are saying that both bug reporters and open source maintainers care about software quality (generally excluding learning projects and research prototypes and the like).
No shit. I don't think anyone has ever disputed that.
In the open source world we generally say that users are not entitled to anything. They get what we feel like giving, because they are not paying us.
This is just as true in the corporate world. If your manager tells you to do X, and some random on twitter wants you to fix bug Y, you do X not Y. The random on twitter probably cares about software quality too. That has no bearing on you probably ignoring them.
Are there any good ways to convert those who comment/suggest into contributors? I feel like instead of simply dismissing suggestions with "you get what you paid for", there must be a better way to handle the situation. Or perhaps I'm too naive on the topic
most of the time when i d̶r̶o̶p̶/contribute a suggestion as a user then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and contribute a patch.
and for those who don't know how, most likely the idea they had is more complex than they would be able to do as a first project, even if they were willing to learn. they are better off contributing in other areas that match their skill-level or enable them to learn. but how to motivate them to work on something that does not relate to their suggestion? maybe by arguing that if they help with those beginner tasks over there, then someone else can find the time to work on their idea, but it feels risky to make that kind of promise.
so i would rather focus on those who say they want to contribute something but don't know what because they feel they don't have the skill. those are hopefully motivated to learn. point them to issues that are suitable for people starting out.
and for anyone else: thank you for the suggestion. patches for this idea are welcome. (and optionally) feel free to ask for pointers how to get started.
That is true, but there are also other issues, such as:
- Knowing most of what to write, but possibly missing some part of the code that you might not know of, which is needed to implement this feature.
They might not accept the change, leading to further things below:
- Possibility of breaking the interface and making it not compatible, especially with future versions of the official program if there are bit fields, structures, enumerations, etc that need to be extended.
- Needing to maintain your own fork of the project.
- If making multiple patches, making them to not interfere with each other.
I had made a repository of unofficial patches of SQLite; currently only contains my own patch for non-Unicode, and list of links to a few others. However, later I should perhaps add also such things as documents about enumerations, etc. Depending what needs to be done, possibly forking it and breaking the interface might have some advantages (can avoid some problems with the existing interface), but also disadvantages (more complicated to maintain).
> most of the time when i drop a suggestion then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and produce a patch.
I had considered this, and I think that you can specify reasons for dropping a suggestion, as well as details of what might be needed even if it is accepted but not implemented yet. As an example, I had made this list:
0. It already has this feature, or this capability can be easily done by the existing features.
1. Yes, I will likely add it soon (and may be working on it already).
2. Yes, but it is not a high priority; it may be added later.
3. Yes, but more work will be needed before it is added.
4. Probably; more work will be needed, and/or design decisions must be made, before it is added.
5. Maybe, but I am unlikely to implement it by myself; if you provide a patch then it will likely be added.
6. Unlikely, but possible. More work will be needed, and I probably will not add it by myself but a patch may be acceptable.
7. No, I consider it to be a bad idea. You may make your own fork of the project if you want it, though.
8. No, it is out of the scope of the intended project. You may make your own fork of the project if you want it.
9. No, it is probably too complicated and not very helpful anyways.
10. No, it is probably impossible. Forking it probably won't help.
11. The request is completely impossible; in addition to being impossible, it might also be incoherent, incomprehensible, unethical, etc.
In the case of bug fixes, it is a bit different, e.g. if you cannot figure out what is wrong, or if you do know what is wrong but you do not know how to fix it, etc.
Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it.
Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
That demotivates me a little about starting simple bug fixing PRs for big projects.
PRs that get ignored is really demotivating. It can depend on which project a lot. If you're new to the project informally (and politely) chatting about your patch on project's irc/discord can help ensure you are not missing any social conventions.
when you fix a problem consider first of all, to do it for yourself. for your experience, or to solve a problem that you actually have.
fixing a problem and then finding out that it is already fixed, or that someone elses later fix was accepted ignoring yours, is also a common experience. there is nothing malicious about it. communication is just not perfect, and for some things, it may just be easier for the known and trusted developers to fix a problem themselves rather than to take the effort to review your contribution, even though taking care of your contribution would give them the opportunity to invite a new contributor. not every project has inviting new contributors on their radar.
my suggestion would be to look at projects that have an explicit policy of being welcoming to new contributors. they will either say on their site or in the documentation, or they have issues that are marked "good for beginners" "or good for a first contribution" or something similar.
work on such issues. join the community, their mailinglists, chat rooms, or whatever they use, and talk to other developers there. get to know the people, help other new contributors, make friends. later when one of your submissions is ignored or overlooked again, those new friends will be able to help you get attention to it. or they may know why it was ignored.
Three years away from having a degree. If you routinely do software engineering, you're a software engineering (possibly s/engineer/develop/ for a similar claim.)
> Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
You are a saint! I would _love_ for people to read through my code looking for bugs and oddities.
Just remember that some FOSS projects are coded well, while others are coded horrendously.
> I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it. > > Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
If you are considering writing a PR, get in touch with developers in a chatroom, or even over email, to coordinate this. They are likely to respond favorably to offers of PRs, and tell you things like "Don't do it now, we have a refactor coming up" or "base yourself off of this branch". And even if they say "not interested, don't bother" - you've still gotten useful information from them.
People who make good faith suggestions can sometimes be converted, but you also have to respect that some people don't have the inclination or time but can still make good suggestions. Sort of similar to how on an internet forum most people are lurkers and that is ok. Good faith suggestions are really valuable to open source projects.
Further, what, precisely, is the paradox? The unfounded assertion that quality exists only in absence of compensation?
Linux was created to meed common needs. For scratching each others' backs and sharing costs and risks, similar to investing in 1/10 of 10 risky enterprises, rather than taking on the full cost of one.
Linux does not care about "software quality, grandiosity, perfection", rather, to get/keep things working and address the needs of its stakeholders: https://www.linuxfoundation.org/our-members-are-our-superpow...
NVIDIA requires signed firmware since Maxwell (GeForce 750, GeForce 900). https://www.phoronix.com/news/MTc5ODA
Which is why I will never buy such a card.
In recent memory I cannot think of any serious open-source software that doesn't have individuals from well-paying tech companies contributing to it in significant ways. These projects are usually of higher quality and are done in the spirit of the open-source ethos - everything is done in the open with open governance etc. Usually expectation is everyone contributes and gets a lot of value for a lot less effort due to the collective effort.
Then, there's a long tail of unpaid software that's put out in GitHub etc. whose quality is highly suspect. They are done as a hobby of an individual, may not even have a proper project community structure (website, mailing list, seeking contributors etc).
Then, there's another category of open-source – these are commercial ventures that want to garner the goodwill associated with open-source model/movement to further the adoption of their commercial offering. Nothing wrong with it, as long as they are honest about it. They are different in some fundamental ways. They intend to control the fate of the project very tightly and privately and there is no open governance of the project. Entirety of the project may not be open-source. Big chunks of the critical functionality may be closed source. At some point they may change the open-source license of the project to make it more onerous.
Some of the best open-source software that I have seen that do both open-source and commercial parts really really well are sqlite, haproxy, nginx.
Because they are popular, people pay and contribute to popular things. Many become popular before they have paying patrons, but once you are popular you will get people who are happy to help pay and contribute.
Surely, it's the other way around. You are likely thinking on projects which are not just popular, but with a target audience so large that they are nearly-mainstream-media-level popular, or alternative, important enough to be necessary for large corporations' activities. For those you may be right, and even there I'm not sure.
Bash? Chet Ramey is employed at a university, but I don't think they pay him to work on it.
https://www.gnu.org/software/bash/
Even if you're Free and Open Source, you're injecting code and ideas into a community. By making that public (and intended for wide use) you are opening up for criticism from anybody to say "I think your software is bad and you should stop promoting it." That's just free speech 101.
if the software is bad, don't use it. if it is dangerous (you could loose work when you use it) then be explicit about the danger. "your software is bad" is a rather useless criticism. tell me why. tell me which alternative is better. tell me what would make my software better. but don't just tell me to stop promoting it, because that is not your place to say.
But, here's the thing in my experience. I might believe believe your software is "bad to the point of harming the ecosystem" (which I do feel about e.g. Wayland, I think they haven't done a good enough job of preserving backward-compatibility, YMMV)
At this stage, it is absolutely my place to say. And very frequently what happens is they put up arguments like yours, even when I have been explicit about the danger, which I do good-faith believe is real enough to get very critical about.
that is the challenge in every human interaction. sometimes it is difficult to tell how a message comes across. if it isn't well received, the best one can do is to back up, apologize that the message didn't come across the way it was meant to and try restating the problem in a different way.
and if that doesn't work, keep trying or give up. some people are just not open to any form of criticism, and the best one can do is to try to be polite and state the problem in neutral terms to anyone who needs to hear it.
Places like this; I don't argue with individuals primarily to privately change their minds. I argue "in public" to get the debate out there and perhaps change the minds of the other readers.
i like to go by this: try to avoid offending anyone with what i say, but also try to not get offended by what others say.
if someone is offended, it could be something that was a trigger, or some misunderstanding, or that person is just to easily offended or there is some deeper issue that i am not aware of.
either way, there is a failure in communication, and if i want to continue the conversation, i need to find away around it. in most cases an apology is a way to do that. not doing anything about the offense assumes that the other person knows that their taking offense is unwarranted. but i believe many don't, or they wouldn't have taken offense.
if the person is reasonable, they will accept the apology and be able to calm down and the discussion can continue. if they are not, the conversation is most likely over, or it escalates. both are things i'd rather avoid.
Code is no different: you only get to tell me how my code should look and feel, or what features it has, if you pay me for it. If I'm creating it for the joy of creating it, then I get to say what it is and what it does. And it's utterly my right to refuse your money, block your comments, and continue doing something with my code that you don't like.
At least in OS you can fork my repo. Then it's your code and you can do what you like with it.
I feel like the paradox of this claim is that paid work seems to be collectively far higher quality software than personal OSS projects. This claim is my opinion, I’m not stating it as fact, and I can certainly think of specific cases of very high quality OSS and very low quality commercial software. That said, in my experience both personal and witnessing others, the sum total open source software has a worse user experience precisely because it’s not catering to what other people need, while paid work might seem less cared for but actually does take care of all the boring chores that need to be done to make software great. Things like good documentation, good unit and end-to-end tests, and polished interfaces, just to name a few. Even just building a GUI is probably eschewed more often by OSS projects because it takes loads more work than making a functional CLI. All these things tend to get skipped more often when you’re writing software for yourself, it certainly has been true for me as well as other people I know. It certainly seems true if you pick random projects to read through on github or npm or whatever, most of it seems like it was a passion project for a month or so before getting abandoned.
> programmers are likely to spend more energies in their open source side projects than during office hours
These remind me of Paul Graham's essay "Holding a Program in One's Head": http://www.paulgraham.com/head.html
> It's striking how often programmers manage to hit all eight points by accident. Someone has an idea for a new project, but because it's not officially sanctioned, he has to do it in off hours—which turn out to be more productive because there are no distractions.
> ordinary programmers working in typical office conditions never really understand the problems they're solving
If the developer has strong knowledge of the business while designing a product, it always ends up with better qa as they are writing the right product on first draft.
You hardly get that when you hire someone to do something for you. That is valid in other domain than programming.