Why do younger coders struggle to break through the FOSS graybeard barrier? Getting involved with open source projects is a great way to build experience in development, documentation, internationalization, and more – but it's not as easy as it should be. Last year, our own Steven J. Vaughan-Nichols wrote that the graying open source community needs fresh blood. That prompted Swedish developer Jesper …
One thing I was conscious of at FOSDEM was that while there are a lot of us of the (slightly) elderly persuasion, overall most attendees were quite a lot younger than myself.
I'm starting to suspect that the problem isn't really bringing in younger developers as such, it's bringing any developers at all into a mature project. So, over time, mature projects tend to stick with the same core of contributors, which naturally ages.
I'm 28 and this matches my experience.
The problem is that CS education has also diverged from being a pursuit, pushing boundaries and building shit "just because," to "applied computer science" with more business-class busywork, project management, etc. You're not allowed to meander on "dead ends" (unless you're shilling AI) and iterate on stuff, so younger devs are indoctrinated to be less patient with some of the more idiosyncratic elements of FOSS.
Depends on the project.
I was at the Embedded Open Source Summit EOSS2023 in Prague, specifically for the Zephyr developer summit. The demographics there are pretty healthy, a lot of young developers there, maybe because it's a fairly new and fast-moving project.
That said, there is a very high bar to getting code accepted to Zephyr, and for good reason. But the other devs are very helpful with pull requests to get it up to the required standard.
I came here to say the same thing. I do software engineering for a living and when you join a new company/team and there's an existing codebase, there's a business incentive to get you up to speed and give you a good overview of the project, support you etc until you're ready to fix bugs/implement features on your own. There's none of that that I've seen in the FOSS world, you're just expected to figure out old and possibly massive codebases on your own.
There's none of that that I've seen in the FOSS world, you're just expected to figure out old and possibly massive codebases on your own.
Some better-organised projects do triage issues out and tag them as "beginner suitable". The idea that they're identified as being technically fairly straightforward (good for a less-experienced developer) and/or give you a decent insight into some part of the codebase.
Of course, these may not appeal to some, as it basically relegates new contributors to bug fixes rather than feature development, which some consider boring... but then that's usually the lot of a junior developer anyway and is how they become a senior developer/architect.
The quality of "on-boarding" is highly variable though.
Unfortunately this also part of the problem. It's human nature to want to improve something and for this improvement to be visible, and unfortunately this can transform into making changes because these are visible and therefore interesting.
Take printing in Microsoft Windows - it's been the unpopular area in Windows for a few decades with no real improvements or fixes during this time. Why? Because it's not only less visible and whizzy than other changes but also it's slightly more difficult than some of the purely visual GUI changes. For this reason printer driver manufacturers, who I am sure employ developers based on the number of lines of code they write for the cheapest price, wound up implementing so much at the driver level that should have been in the Operating System. Which led to both of Microsoft's failures in the Print Nightmare vulnerabilities and the subsequent even worse printing environment that was rushed out and inflicted on the world.
Similar stories are to be found everywhere... would a developer prefer to work on the asynchronous storage of configuration settings and to track down an initialisation issue that is probably timing related due to the configuration changes, or would instead prefer to change the order and naming menu items in the main interface? Guess which gets the most changes...
Well, that's really exploitative, and you don't even become rich, most ot the time. As more and more people see some developers getting rich selling their startup to some IT Moloch, I think only people with a religious attitude would choose to sacrifice themselves. Espeically in a society that is become more and more exclusive and costlier.
FOSS is not a sustanable model and doomed to fail.
Absolutely disagree. I contribute to several projects and this regularly sends work my way. If you actually know a real world system inside and out, there are people who want to leverage your knowledge to help introduce it into their work.
Contracts like these tend to work as part development / design, part training developers within the company on the software / mindset of said project.
Been my experience as well. The work on open souces projects themselves may or may not be financially rewarding, your experience with it almost certainly will be. And there has been a change over the last 20 years or so. Back in the early 2000s, companies were, somewhat understandably, wary about engaging in open source and potentially contracting for improvements or changes without ownership. That is no longer the case as many CIOs or CTOs have grown up with open source themselves, appreciate the value is in the openness and are comfortable engaging with developers.
That makes no sense. If you combine time "donated" to FOSS with what salary you might get, you'll be barely better off than person stacking shelves - at least in the UK.
It is really about ego, to show off hey I can code! look! Open source is perfect for that.
But you also give a signal to employers, that they can exploit you.
@elsergio: You're a brave man, coming here and uttering that. With that attitude, I hope you only use fully paid software products? Assure me that is the case, please.
I'm afraid my days of coding anything are long, long behind me, but I have immense respect for the work of those who have and do chip in with their expertise, and I make modest donations where it seem appropriate.
"But you also give a signal to employers, that they can exploit you"
Well in my almost 50 years of experience with over ten companies (only one of which is still in business, and no they all failed or were bought out well after I left) only one did not try to exploit me. It was my last full time job and the best one I ever had. Good boss, fully understood my level of embedded programming expertise, let me get the jobs done without getting in the way, and paid me well. And I worked hard to make sure he got his money's worth. Unfortunately for me it only lasted two years.
time "donated" to FOSS
that's the same time some people "donate" to playing music, building model trains, gardening, or watching TV (or writing comments on ElReg !). While I love trekking outside, I absolutely loath gardening, but I understand that it's enjoyable for others. The same is – probably – true for most FOSS contributors at their beginnings. Heck, it was true for me, I did it out of pure intellectual curiosity and to "scratch an itch".
This. Absolutely this. I don't "donate" my time to FOSS. I do it out of curiosity, or to develop a feature/application that I want.
Not everything has to be a transaction, sometimes there are other motivations.
I either have to VAT register, or take a few months off each year, depending on how I feel, so go figure.
Your singular poor experience doesn't reflect the reality of others, and none of the projects I contribute to are nodejs or php projects, if that helps...
Correct. Two people in this thread, including me have had positive experience, and I have multiple friends who have similar. I'm merely sharing my experience, not broadly describing the state of affairs universally. You could have just said "Not in my experience" and not come across quite as contrite, but you do you I guess.
> You could have just said "Not in my experience" and not come across quite as contrite
Oh, if only he were contrite, what a change that would make!
(Gonna assume you tried to type "contrary" and autocorrect got to it first)
You could have just said "Not in my experience"
I suspect that might have been a difficult thing to have said.
But backing up to your reluctance to VAT registration - I find that surprising. When I was freelance my clients were VAT registered businesses so would be setting my VAT against their own VAT; in fact thay might have been expecting it and possibly reluctant to deal with somebody who wasn't. The VAT accounting was the simplest bit of the book-keeping (which I just handed over to an accountant anyway) and it meant being able to claim back VAT on any business purchases.
Very much this.
I spent all but 3 years of my working life as a freelancer and pretty much the first thing I did was a voluntary registration for VAT as I turned over way less than the threshold. All my clients were businesses so it had no effect on them as they were all VAT registered, and getting the VAT back on all the shiny kit I bought myself was a no-brainer.
One word of caution. The accounts are straightforward enough but being VAT registered means that you will get the occasional VAT inspection. Do not mess with the inspectors! They have wide ranging powers and I seem to recall don't even need warrants to undertake searches, so make damn sure your accounts are up to date.
It very much depends on your attitude to various risks and costs.
For many, avoiding the extra work in managing VAT is worth losing out on VAT recovered from purchases. And when your main output is your time, and inputs minimal, that weighs towards not registering.
Once you are VAT registered, then you are immediately into quarterly returns, mandatory use of digital tools to submit them, risk of inspections, etc. ,etc.
We have a small rental business, fortunately well below the threshold for MTD (making tax digital) which (IIRC) is currently the same as the VAT threshold. I use a spreadsheet for the accounts - it's simple, easy, reliable, and above all EASY TO SPOT ERRORS ! I have tried using management software, but it was a p.i.t.a. - just simple things like buying a tin of paint, on the spreadsheet: enter it as a line, put the cost against the relevant column, and the second entry against the source of payment, see if the check column (just a sum across the columns for that line) is showing empty. Looking over it when doing the year end, I can see if I've missed an entry quite easily (I pre-populate 13 lines for mortgage payments & interest, 12 lines for rent, and so on - all with dummy values that show as errors until the right figures are put in). The management software made it so hard to see an overview that when I found multiple errors where it didn't agree with my spreadsheet - it took time to find them (all of them errors in using the software, none in my spreadsheet). So I've ditched using that. On and off I also have a little sideline going, again simple accounts on a spreadsheet.
If I had to go MTD, I'd have to do that as it's mandatory. So I'd be doing all the accounting twice - the easy way, and the HMRC approved way, simply so I could be sure I had my figures right. All the blurb keeps saying how there's lots of benefits to MTD - I see none at all (and I really do mean none at all), only added costs and complexities.
> I either have to VAT register
Problem?
If you are selling your services, rather than selling products, the Flat Rate Scheme is very simple, although you do have to maintain accounts (I’ve not found the need to use anything more complex than a spreadsheet package) and submit VAT returns every three months (This has to be done digitally, I use VitalTax @ £20 Pa).
Sources? It looks developers doing commercial software get a good pay in Western countries - not in India sweat shop, true. Now, if you work in a company that allows you to spend part of your time contributing to open source projects they use, it could be OK - it's still you work schedule and you get pay at market rates. Otherwise I understand why young people steer away.
The reality is that due to the "free as in beer" nature of open source, most developers couldn't make a living writing FOSS code alone. So developing it is really a highly technical, greatly time-consuming hobby rather than their day job. Open source has reduced the perceived value of software and software developers.
People have very weird, and often self-serving, ideas about FLOSS. The term 'open source' is horribly abused, just for starters.
In the end, like any human activity, FLOSS is open to all the greedy and exploitative behaviour common to humanity, but at its heart it's what happens when someone, or some team, need to scratch a software itch and are generous hearted enough to share the results with anyone else who cares to use the code. Everything that happens beyond that, for better and for worse, is just detail.
So, if Jane chooses to spend all her waking downtime labouring over her chosen code mountain, while some corporate Moloch runs off with all the money on the back of her efforts, that's her choice. Someone else may make a different choice about how much downtime, or any time, they choose to give to their chosen code mountain.
> most developers couldn't make a living writing FOSS code alone
No longer true, no. Decades ago, maybe.
In my role before the Reg I worked in a company with many hundreds of FOSS developers. The role 2 or 3 before that is about 5km from where I am sitting and employs several thousand people across 4 or 5 large buildings, all hammering out the C (and doubtless dozens of other languages) 40+ hours a week.
One thing I see as a contributor to a long-existing and large FOSS project is the generational difference in coding styles.
It quite often occurs that contributions from the new generation needs a fair amount of work simply because the younger coders have been taught different styles of coding to older ones.
And for a mature project, everything is in the older style simply due to being written by people who grew up learning such older/established standards.
If the new stuff gets included as-is, then you get issues of readability and debugging, but conversely it's not unknown for newer coders to get disheartened by the requirement to follow standards (especially given the volunteer nature of the contribution, even leaving aside any "ego" thinking that the code is perfect as it works).
And unfortunately I can see tools like ChatGPT and CoPilot potentially making this even worse, or requiring older code to be completely rewritten if it's output does become the new standard.
I'm a long retired coding fossil now, but just during my own career, the conventions changed more than once for how you name variables, functions and subroutines. I've no idea what the conventions are now. It can be a little disorienting reading code written in a different style. Lack of suitable coding comments can be a real issue too with complex code.
Tools and methods change as well which results in younger people being reluctant to learn 'old' languages and methods. They'll be quite willing to rewrite code using their favored toolsets but not so willing to delve into the kind of intractable logic problems that you'll find in mature systems. Experienced programmers are likely to push back because they know that while this approach may fix one bug its likely to introduce several more. So its really not "FOSS Graybeards holding back progress" but rather the need to tread carefully and work methodically, even slowly, which for many brought up on the instant gratification of frameworks and coding assistants is too confining.
I'm from the "build it from scratch" generation, and I love the intractable logic problems. I am finding that youngsters get stuck if there isn't a "framework for that", it's like they've been taught to code the same way toddlers are taugh to assemble Lego bricks. But once you point out to them that it's an intellectucal challenge and nobody actually knows how to solve it yet, most of them figure it out quite quickly.
This too. There are far too many so called professional developers that have no clue about writing robust code that when it fails does so in a controlled and useful way. "Range checking and error handling? Pah! That can just be left to the exception handler and some other part of the application" seems to be a far too common failing. As a result, we get incompetently useless exception messages for expected issues. For example, attempt to save a file and the file is locked by some other process and rather than getting a message telling us this we instead get an utterly useless exception raised that very unhelpfully states something like "invalid byte count" rather than "unable to save file as it is locked by another process".
But then these are the same mentality of people who always specified "on error continue" within Visual Basic and disabled every compiler warning and notice on any later environment they polluted through use.
"(...) if you're contributing your own code, there is a high bar to clear. It often feels as if you need to surpass whatever the existing functionality is. Just to get accepted, you have to offer something better than some existing product that may have been around for decades."
If you have nothing better to offer than what already exists, what is the value of your contribution?
Contributing where there isn't existing code.
You aren't going to be making a contribution to the Linux kernel, same way as you aren't getting on the C++ standards committee as an intern
But Github is full of niche projects where there isn't an 800lb gorilla.
Especially in small HW, when Linux took off it was still difficult to make small electronics without paying $$$ for dev kits and building your own HW - now with RPi, Arduino , ESP32 etc you can build real world gadgets with a clever idea, $10 at Aliexpress and a dozen lines of embedded python
> Another gate opener...
That's something that I seriously considered myself. We have one that is proprietary and I want it to do some stuff that it wont do. I also would love to have the time to design a Pi-based washing machine controller.
Honestly, it doesn't matter if there are a 1000 projects out there like this. The point is that it is cool and the amount of experience gained by doing it is immensely valuable.
You really need to get out more. The low end stuff can do a *lot* more than blink LEDs.
Straight away I can think of the PicoGUS : https://github.com/polpo/picogus
or the Picomem : https://github.com/FreddyVRetro/ISA-PicoMEM
Memory emulation with 16Kb Address granularity:
128Kb of RAM can be emulated from the Pi Pico internal RAM with No Wait State. We can emulate the whole 1Mb of RAM address space from the PSRAM. (With 4-5 Wait States added) 4MB of EMS Emulation . Memory emulation is used to add 4Kb of "Private" memory for the PicoMEM BIOS Usage. PicoMEM Disks data transfer done via the emulated Memory.
ROM Emulation for its internal BIOS and custom ROM loaded from the MicroSD. (Custom ROM not implemented yet)
The Board has its own BIOS, used to automatically detect/Extend/Configure the RAM emulation and select Floppy/Disk images.
Floppy and Disk "emulation" from .img files stored in uSD through FasFs and DosBOX int13h emulation code.
Emulate 2 Floppy and 4 Disk (80h to 83h), Disk up to 4Gb (More later)
USB Mouse support through a USB OTC Adapter. (Micro USB to USB A or USB Hub)
POST Code (Port 80 Display in Hexa) via the QwiiC connector: https://www.sparkfun.com/products/16916
ne2000 network card emulation via Wifi (Pico W PicoMEM only)
USB Joystick for PS4 and Xinput controllers.
Adlib using a PCM5102 I2S module.
NEW: CMS/Game Blaster and Tandy sound chip are now supported.
NEW: Tandy 1000 (Old models with Tandy Graphic) now supported, even for RAM upgrade.
> Floppy disk image emulators? as opposed to a USB key?
You do know that you can't plug a USB key into a port that expects a floppy disk? Unless you have an emulator to make it look like (s pile of) floppy disk images?
> USB mouse? as opposed to a *decent* one that you can buy for cheap?
No, that is another adapter that lets you plug your "*decent*" mouse into a system that otherwise won't accept it.
> These are at best solutions in search of a problem.
So, you aren't a member of the retro-computing community, the ones that are working hard to keep old systems alive and working (as best they can, given the lack of new floppy disk stocks or serial/other mice in the shops).
> Even as a hobby, "Do it and learn," this doesn't interest me.
Well, as you really didn't understand that post, it isn't a surprise it doesn't interest you. And as you never tried to learn what was being talked about before replying..
Please understand that not every project is intended for you. This is intended to plug in to the first generation of 8088/8086 PCs. Getting anything prior to a pentium going (when PCI became generally available, and everything was using PS/2) can be a real pain.
Tandy graphics were a real improvement over CGA in the very early PC days. How about doing a search - it's the very first hit on Google.
The advantage of using a floppy disk emulator - whether this mode of the PicoMem, or a Gotek, is that it works with the host system without drivers
The card also offers functionality that would previously be contained in several dedicated (and expensive) cards in one inexpensive card.
It's very much a solution to a known problem.
It's the same with the PicoGUS. The Gravis Ultrasound is an overrated sound card that is only really useful with Jazz Jackrabbit, Pinball Fantasies, and a few demoscene demos from the mid nineties. Nevertheless an original GUS will set you back a minimum of two hundred pounds upwards, whilst a PicoGUS will do pretty much the same thing for under sixty.
I've built my own SmartHome devices to control LEDs (I mean like LED lightning in whole rooms) with custom animations, automatic curtains, the garage gate, garden lights, UPS for my router rack etc.
I have the stuff integrated via my own hub that talks MQTT with Home Assistant (OSS Smart Home hub software), and using long range radio modules (such as LoRa) to connect much further than normal ZigBee (a commercial radio standard for SmartHomes) can do.
Seriously, the amount of devices, robots and automations you can build yourself today with microcontrollers and modules in your own home lab is practically unlimited. Add a 3D printer and you can make even more.
This isn't rocket science - it's just about having the imagination to see what's possible.
Quote
"Yep, another LED blinker or gate opener. These toy controllers are too basic to make something remotely interesting with them."
Strange you may say that, however, what do you think opens and shuts the safety gate on our robotic machines (ok it is'nt a Pi) , its a controller that moniters inputs, ie does the machine want to open the gate? is the gate unlocked? is the gate in open position after air applied to the piston? send command back to the machinery saying "safe to put the arm in" then the machine sends the command to shut the gate, so its air to the piston to close, is the gate in closed position? apply locking bolt , is the gate locked? send command back to the machinery 'gate closed and locked'
Theres some other inputs/conditions to be met, but the above is a basic description.
Now say someone gaining experience with a Pi to open a gate or flash some lights wont be able to use that knowledge to make stuff more interesting in the future
> These toy controllers are too basic to make something remotely interesting with them
IBM PC 5150 released with 16KiB of memory (motherboard can hold up to 256KiB, expansion cards up to 650Kib), 16-bit CPU (8 bit bus) at 4.77MHz; basic model ($1,565 woth 16KiB) had no floppy. Dual floppies held 350KiB each. Mains power required. Expansion required to add video output (CGA included in that price), RAM expansion and any i/o (serial or parallel printer ports).
Raspberry Pi RP2350 MCU: bare processor provides 520KiB RAM, dual-core 32-bit CPU at 133MHz; available with in-package 2MiB Flash storage; expansion allows up to 16MiB of RAM/Flash mix; USB 1.1 including PHY; 2x UART TTL serial, lots of other GPIO, timers, PWM. Runs off 5V USB, battery power very possible.
Basic Raspberry Pi Pico 2 board: "Basic" RP2350 with 4MiB Flash (£4.80 at Pi Hut).
Ah yes, I fondly remember the early '80's, when we were paid to sit around all day with our single-floppy IBM PCs, playing cards, reading the newspaper and dunking digestive biscuits whilst we reassured our managers that in only a few years time they'd release an IBM PC compatible that had enough resources that we could *finally* do something remotely interesting with them.
> These toy controllers are too basic to make something remotely interesting with them
A very similar idiotic mentality to someone on here who tried to argue that a Commodore 64 wasn't a computer because it didn't have an excess of resources, 3D graphics and acceleration, bulk storage such as IDE or M3 controller.
The Commodore 64 was immensely capable compared to any other similar system at the time and definitely compared to what was prior to it. That a single icon for an application in Microsoft Windows might not fit into the entire memory space of the Commodore 64 just shows the gulf in resources and how they no longer need to be conserved and used incredibly carefully in the same way, What was implemented on a Commodore 64 at the time was due to hard work and clever implementation and not the concept of "optimising a computer programme by adding more RAM and a faster processor".
Hmm let's see. In 1980 or so I was working for a company that had developed a prototyping system for microprocessor real time applications. Plug together units such as i/o, relays, a/d converters via edge connectors, get coding (in MicroVera as I recall) and get the system running. When it's finalised, take the artwork for the relevant units, cut off the edge connectors, join them up and you've got the circuit design for your custom controller.
And what were these controllers used for? A little thing called "process control", you know, like running whole factories. Not bad for a toy.
You're really trying to argue that microcontrollers that you can buy for a few dozen *currency* at most, with more computational power than what was used to send people to the moon (and back) are "too basic".... That sounds like a you problem, a lack of imagination, not a problem with those microcontrollers.
Adding better test coverage to a particular feature set would be something a lot of projects would benefit from and appreciate, without requiring a huge investment, for example.
Large, well managed projects also often have a "good first issue" tag, which can help people gain familiarity as well.
I think the problem to a certain extent is, particularly with new developers, there is no real guidance to how any of this works, and it will often require reaching out to the developers directly to find out where to begin, which instantly discounts a lot of people nervous to do so.
"surpass whatever the existing functionality is" != "nothing better to offer"
* An overly-complex and/or poorly-factored chunk of code can many times be improved by being re-designed and/or re-written, particularly if it has been involved in a large number of bugs.
* You have to be careful not to get into "revision wars".
* Don't think you have to create some huge, monumental thing. That leads to madness, and abominations such as systemd.
I think there's also another possible factor to consider. Having offered opportunities for involvement in foss projects both independently and through universities, I've found no young developers have been interested unless [a] it's a mass market or trendy product or [b] there's payment involved. There seems to be no desire for intellectual challenge or recognition of engagement as a path to professional development, just a desire for kudos or dosh.
So so true.
As the son of a technically-illiterate Polish immigrant I was lucky enough to receive a grammar school education and then a university degree where I received a grant, including the fourth year that I needed after indulging in the social life of the University of Sussex in the 1970s!
A few years later I not only got a grant for my MSc, but it close to doubled the standard grant as I was now a "mature student" returning to education. That was followed by 3 years as a Research Assistant and Fellow but that was technically as an employee of the college. My outlay? Precisely zero.
Read it and weep millennials, you have my utmost sympathy. There is no way that I or my siblings would have received our university education today. Quick example with the benefit of hindsight, the first bike I got for Christmas was second hand and too big for me but that's all they could afford.
I wish I'd kept the URL, but one of the comments I remember from my introductory experiences with Reddit (admittedly, I was rather late to that particular party, so it was probably within the last five years) was from some random person who described how they scanned through the open issues on GitHub, looking for projects that were sufficiently important/had enough downloads/lots of stars in order to find ones that were worthy of his contribution.
Which, with that phrasing, sounds like a smug and overestimating person. However, with slight modifications, it could sound a lot more normal. For example, joining a small project that nobody uses may not be a good first contribution because there's a chance that, with few contributors, their code might not get the reviews it needs. That could go either the way where nobody reviews it because it is a mostly inactive project or one where the people working on it don't want to deal with a young contributor or the way where, because so few people try to contribute, reviews are cursory and any new code gets sent through if it passes the tests. If nobody uses it, then maybe time spent adding code to it is wasted. A larger project might have better resources for a new contributor.
I'm not saying they meant it that way, just that there can be a lot of different ways that someone might look for something to contribute to. Not everyone who stays away from open source is doing it because they want fame or cash for every contribution. Some of them might be worried about whether they're wasting their time, whether they will be able to use skills they aren't certain of without either breaking something or getting shouted at, or many more understandable things.
Not going to argue with you, those are all good reasons for looking for an active project to start with.
Sadly, the person I was referring to was (apparently) already a contributor to projects, so wasn't trying to break into the game. I think it really stuck in my head because, on that page at least, nobody disagreed with them (or I'd've gleefully recounted the hordes of Redditors slashing away in response).
> Some of them might be worried about whether they're wasting their time, whether they will be able to use skills they aren't certain of without either breaking something or getting shouted at, or many more understandable things.
FWIW[1] I'd suggest looking for a project that doesn't have a mass of activity, is a piece of software that you actually use, a lot, and which has something you believe is missing/needs improvement[2]. That way you can do the changes to improve your day to day experience, without spending hours integrating a mass of code churn[3], and you get the time to do a load of real-world testing of your idea & your code before taking the plunge and offering it up. And because it is something that is demonstrably useful to you, even if it gets rejected a couple of times (coding style, whatever) there is still purpose behind continuing with that code, which makes it sensible to then keep your mods alive, locally, for a while before working up to submitting it again. Finally, this approach means that there actually is a really good reason for you to try - and try again: if it gets accepted you'll be spared having to merge your changes back in every time the project updates!
[1] not a lot, really, but I have your attention now, bwa ha haah
[2] yes, this is simply the "scratching an itch" approach, nothing novel, just wanted to expand on why it is a sensible one for a newbie contributor to take
[3] as you gain experience, this just becomes "one of those things" but it is always easier if people just stay the heck away from the area you are working on!
Is the best way I've found to getting into a project: you're using something and it doesn't do quite what you want or it has a bug. I susepct this is how most people get involved and how you maintainers handle it is key. In my experience, if someone is really interested then they will invest time and effort into learning what is necessary to do. Maintainers can help them along but the real experience of learning how to do something can itsef be rewarding.
But I've also learned to be picky because, unfortunately, there is also a culture of entitlement that means people bitch about stuff but aren't prepared to contribute time and effort to fix things. Basically, they're wasting our time and we could just tell them to fuck off and sometimes that's really the only way: users are not customers.
We recently had a talk about maintaininng SciPy and my advice was that: you can make changes to the API, including breaking it, if you feel they're necessary, you're doing the work and you communicate it properly. Users who want things to stay that way, because they've always been like that, probably aren't worth listening. "Foolish consistency is the hobgoblin on tiny minds" as the Zen of Python puts it.
I remember reading a thread on the Duplicity mailing list where somebody complained about the software and outright called Ken Loafman incompetent. Ken, in a surprisingly polite way, told him he didn't know what he was talking about, presented his credentials, and (I think) kicked out the troll. (Good riddance.) Developers should not have to put up with that kind of abuse, especially for doing a good job maintaining good software.
What always amazes me is the sense of entitlement from some users of *free* software. You've been given it for free FFS!
Quick example from Raydon's firmware update for Humax satellite boxes. Some muppet comes on the forum to say that it's a crock of shit because you have to perform a soft reset in the web interface in order to activate recordings set that way. It's a hardware limitation of the platform you plonker.
"Better to remain silent and be thought a fool than to open your mouth and prove it"
I fully agree with finding something, and that there is a culture of entitlement.
However I would be very careful about breaking APIs. Users are *always* worth listening to. Of course they want things to stay the same, because everything you change means more effort for them.
There has to be a good reason to break compatibility, and once the popularity of the project expands beyond a certain stage someone will undoubtedly be using it in an unusual manner that pushes the expected use case. That doesn't mean what they're doing is necessarily incorrect, and any change should deliver a material benefit to the end user.
Of course, if this is provided for free with no commercial support, feel open to do what you want - but it may affect uptake and usage of the project. For commercial support, it's a whole different matter. There's a reason Windows has excellent backwards compatibility.
APIs should be stable, although I know that's anathema to sections of Linux. If the API is that bad and needs revising, create API version 2 and add in addition to the first version.
> Users are *always* worth listening to.
Why? It's not their software. If they want it to work in a particular way they have all the tools at their disposal to make it do so. Why should anyone hobble themselves to accomodate their laziness?
> any change should deliver a material benefit to the end user.
If users want some material benefits they can offer some material money.
> it may affect uptake and usage of the project.
Is this project the solution to someone's problem or the extension of a developer's ego?
@ChoHag
If software is offered to the public under an open source licence of some kind, there is an assumption that people might want to use it. The licence will usually make clear that there is no warranty of fitness for a particular purpose &c, and generally no guarantee at all. But using the software entails the user spending time with the software, exploring their application, and the opportunity cost of not using something else.
An API it strikes me is like some kind of undertaking by the developer of the software, along the lines of 'we might change the way we provide these affordances, but the affordances will work'. Some projects depreciate APIs but they usually give plenty of warning so users who depend on the depreciated feature can go elsewhere.
So not so much 'hobbling' the developer but expecting the developer to continue in roughly the same direction.
Perhaps releasing a project as 'source only, no guarantee of updates, no bug reports or pull-requests accepted' upfront would be a good way of managing the situation? I believe some projects do that.
If the API is that bad and needs revising, create API version 2 and add in addition to the first version.
This. APIs should be versioned, especially in these days of dynamic libraries. Changing an existing API can dump you straight into dependency hell, the bane of any Linux developers life, where one component needs APIv1 and another needs APIv2, and you can't install both module versions at the same time.
I did say that, if you feel the need to break an API, then at least communicate it properly, and, yes using a new version after announcing the future change is the best way to do this.
I do listen to users but I no longer feel obliged to take what they say seriously. However, it's usually not a good idea to get into a slanging match with them: the real idiots have normally got way more time and energy. But they'll usually go if they don't get the kind of response they're looking for.
The article talks about young people having a high bar to submit something new. Most projects that I use have much more need of people to fix bugs, write documentation, etc. than to add yet another half-broken feature hardly anybody wants. (I fix bugs when I can, but some things (e.g. the Xorg input/events layers) are just too hard). It's hard, not always interesting, work.
There are tons of projects out there that younger people have written for fun - games written in Python, home science projects, all sorts of things. A lot of it isn't of great "professional" quality, but so what? Everybody's gotta start somewhere, and complaining that you can't get code into the Linux kernel or some other big name project at the age of 24 is a bit like a newly qualified engineer complaining that they don't get to design a big suspension bridge but have to maintain small unexciting things : you have to earn the experience and prove yourself to progress up to the big stuff.
I suspect a lot of complaining from the younger folks comes from people used to a world of instant online celebrity who feel this should apply to online code contributing too. The older folks complaining about the quality of young people's work have forgotten that they were once young and inexperienced too. Younger folk who are into programming are going to grow older and wiser themselves, and have new ideas and start projects of their own which will have their own successes and failures. They may well develop ideas and practices which feel alien and objectionable to people used to current ones. But this is what progress looks like, and has always been the way of the world.
In the olden days, learning assember & the microcode was essential to producing efficient code. For example, Data General Nova's had a "Jump Through" instruction. If you jumped through a certain register, it would pass you to the address in the register and then increment it. Fantasic efficient use of code.
I am sure there are similar 'shortcuts' that the "greybeards" know and use. But anyone new, learning from college courses, probably won't learn about this, produce iniefficient (relatively speaking) code and get disillusioned when their entry is rejected.
So, who is educating the newbies on the best practices for efficiency?
Alan
@AlanSh:
I think you're wayyyy mis-remembering things.
1. The Nova series had eight auto-increment memory (vs register) locations on page 0, at \20 ... \27, and eight auto-decrement locations on page 0, at \30 ... \37. I didn't see anything in the docs about auto-increment registers (excluding the program counter). Per Programmer's Reference Series NOVA Line Computers, printed July, 1979.
2. Why would you want to indirectly jump through an auto-incrementing location? If you did so, you'd be jumping to a series of sequential locations: n, n+1, n+2, n+3 ... which is something normal program flow would do for you (after the initial jump), as the program counter auto-increments.
Its strange, I know plenty of younger people who have jumped on mailing lists and immediately got involved contributing code (in C).
Way more than a decade or so ago. Perhaps the big gap between the Z81 / ZX Spectrum era and the Raspberry Pi is what caused the temporary decrease. It looks like that is resolved now.
I'm not much of a programmer, so I can't weigh in on what "kids today" do or don't know, but, based on years of reading these comment pages, it seems like a huge barrier to entry would be the world-weariness and cynicism of the older generation. I see a lot of grousing about habits of younger programmers, but I haven't read any stories about older programmers mentoring younger ones. Perhaps the graybeards could try taking the youth under their wings and helping them grow. Perhaps you guys might actually learn something useful from the new kids as well if you opened your minds.
Just my two cents.
OTOH once you get enough experience under your belt, let the years roll by and your beard whiten, it is the damn fools who stick in your mind - and certainly make for better anecdotes in a forum like this. So that is what you are going to read about here.
Like your drive home - you remember vividly the two prats who tailgated you but the two or three hundred other cars who were also sharing the motorway this afternoon made no impression on you at all, just a gentle background drone.
I've also had many pleasurable days in work, going over the ins and outs of code with colleagues - who all seemed progressively younger! But how well I successfully "mentored" them? Haven't a clue! I just took enough encouragement from the occasional "Ta" to keep on getting up, wandering over and seeing how things were getting on, what new toys they had found that I could then pick their brains about. There you are, that was a riveting read, eh!
Speaking only for myself a very graybeard, I have always been willing to help younger programmers in my limited area of expertise and have done so in the past. I would like to add that some of the younger ones didn't want/need my advice. I was OK with that as long as I didn't have to go back and fix their code.
Indeed FOSS is very much accessible to people who are rich and can donate time.
Unless you have rich parents and you don't have to worry about paying rent, putting food on the table, making contribution to FOSS is out of reach.
Sure, some people can do it, typically those on the spectrum who don't have cravings for social life or those who think they can change the world by providing free alternative to what greedy corporations are offering, whilst living on instant noodles and still living with parents.
There is not much that can be done, apart from making corporations that use FOSS paying royalties to contributors, so they can make sustainable and good living.
Otherwise? Forget it.
"Indeed FOSS is very much accessible to people who are rich and can donate time."
Nobody is forcing anybody to contribute their skills or time to FOSS, so I struggle to work out why you're so negative about it. In a typical lifetime, most people go through periods when they may be cash rich, or time rich, or poor of either or both. If they choose to spend some of their time on FOSS, then I take my hat off to them.
I do a day job that pays 30% less than the going corporate rate for my skills and experience, and I do it because I enjoy it and because it contributes positively to society. Will you disparage me, my choices and tell me to forget it?
If you're burning the candle at both ends trying to make enough cash to survive, then obviously you're not going to contribute.
But - FOSS can really help you. It gives you the software you need for free.
Later on if you're in a better situation, you might have some time to give back to some FOSS projects - "paying it forward".
And not merely code.
Documentation and tutorials are often far more valuable than code.
> Sure, some people can do it, typically those on the spectrum who don't have cravings for social life or those who think they can change the world by providing free alternative to what greedy corporations are offering, whilst living on instant noodles and still living with parents.
You watch *far, far* too much TV. I suggest you get out and see the world, it is rather more nuanced and varied than you seem to think.
There's some valid insights there including, again pay people but several points are obvious rubbish
"It often feels as if you need to surpass whatever the existing functionality is". No, it doesn't. It's incredibly trivial to find areas lacking attention. Definitely on BSD, sure it's the same on Linux. Use it on an every day basis and very quickly you'll have a laundry list of things that are easier on Windows, or simply don't exist. If on the other hand what you're looking to do is find fame, fortune, or surpass a huge well known project that's a completely different matter.
"Funding matters, but it's not the only problem. You can't really fund time.". bulllllllllllshit. I do my boring corporate job because it pays the bills and provides an adequate work/life balance. If someone offered me most of the income on the grounds I spent a non trivial amount of time on open source I'd go for it, even knowing all the other downsides of contributing to open source.
Olsson seems to be repeatedly assuming open source is an altruistic activity conducted outside work hours that eats into personal and family time. If developers were funded to code 9-5 that would not be the case.
So many of the problems can be boiled down to 'there's not enough money to fund developers, support, and infrastructure' and this is also a direct consequence of much of open source historically and presently concentrating on 'free as in beer' rather than 'free code to distribute'. It needs a sea change in attitude.
There's also the very understandable human attitude of a notable proportion of open source developers who basically want to dick around with code without any of the downsides - such as having to liaise with other people, provide support, handle irritatingly rare and unusual edge cases, manage infrastructure (web sites, github, yadda yadda), oh and also magically earn money whilst not having to compete with commercial competitors. If they're doing this for free they of course have the option to do exactly what they want when they want, but understand this carries the usual downsides with interacting with other humans and how much they're prepared to take up and contribute to the project.
Even if you've never written a line of code, a good bug report can be written by anyone and is always valued.
Even with our customers - all programmers - we still get the "it didn't work", plus if we're lucky a screenshot of some code in an MS word document. But the reports that come in with a version number, a stacktrace, and method or code to reproduce? I love those people.
Because it's the only way the best of experiences to ever exist. In the legal gray for any one to mirror improve and tweak to their own use.
Also helps to give modern access to those with very little pocket money.
Because nothing off-the-shelf is a good enough until adjusted to specific circumstances.
The vacancies are everywhere, and hardly difficult to find.
It (probably) pays nothing upfront, although the coding experience and social networking aspect may well pay future dividends in finding paid work. You (probably) do it simply because you enjoy coding (and I for one would avoid employing a programmer who didn't), and/or wish to gain hands-on experience in real-world software projects, and/or think that contributing to software that is useful, affordable, adaptable and transparent is a Good Thing.
If it's all about the money you may well be in the wrong profession.
"It often feels as if you need to surpass whatever the existing functionality is."
Well yes. That's what contributing code is - you're supposed to make it better. Faster, does more, less code or similar.
To be making changes just to see your code in there instead of whatever was there before is pandering to ego.
One of the barriers is employers. I've had contracts in the past that have said that all intellectual property I created, even on my own time, belonged to the company. I do wonder how often that happens and how they enforce it.
To be fair though, I pushed back on it with that employed, citing open source, and they did actually relent and changed it to any IP directly related to my job (which I was OK with; besides which they were in an industry with such high barriers and so few players that taking IP to a competitor would probably get you instantly blacklisted). But the idea that if I wrote a novel or painted a picture, the copyright belonged to them? Nope.
I'd be concerned about AI becoming a barrier. I was going to open source a project I've been working on, but when I realised that all my inventiveness, creativity, research and knowledge would be scraped to train an AI so that some corporation can use my work for "free", why bother?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
