A there good guides, live examples of how Agile (or any of its popular forms) are used in open source projects of moderate complexity (eg over 3 years old and over 1.5mln lines of code)?
A there good guides, live examples of how Agile (or any of its popular forms) are used in open source projects of moderate complexity (eg over 3 years old and over 1.5mln lines of code)?
Don’t do it. Agile is essentially accepting defeat on the face of an industry flooded with an outrageous lack of competence and quality standards. It’s a set of mitigation strategies that has have failure as starting point and so make things somewhat better.
My characterization of agile is different, but also unflattering: it’s a coping mechanism to make it more bearable to deal with stakeholders who are unwilling or unable to think rigorously about what they’re asking for. And it is also a feedback mechanism that, when it’s sucessful, eliminates any remaining motivation for stakeholders to think clearly.
Little of which applies to a typical open-source project, so my conclusion is the same: Don’t do it.
If you’re making software for a bank, then agile makes a lot of sense. Most software engineers aren’t experts in banking and have no idea what is needed in a banking application. So you have domain experts (product managers) making the requirements, and working with the engineers to accomplish them.
For a highly technical project like an operating system where the engineers likely have the best domain knowledge, or something where there are really no domain experts like a consumer product, this is usually superfluous.
Thank you, but projects like FreeBSD or much smaller ones (hopefully there are some examples)
don’t the OSS projects have Scrum masters, product owners, Release Train Engineers, don’t they estimate stories with story points (to see if a given feature will fit into a release)?
I understand that OSS projects may not need to plan for budget, so the project leaders do not need to have budgets, but the projects that have fixed release cadence, they have to estimate and predict the amount of work it may take. Or am I wrong?
No, they don’t have any of those. Whatever makes it into a release is what makes it. OSS projects take a very natural approach to work. The extremely high asynchronous working nature of OSS dev calls for it. Remember for majority of FOSS, everything is volunteer work, or a work of passion, usually by a handful of individuals.
To me it seems you don’t have much exposure in the space. It could help us if you explain your background or context a little more. The question seems really “out there”, like you’ve never been exposed to FOSS software (which is unorthodox for a lot of us here).
FreeBSD doesn’t have any of these. It has a release engineer, who is responsible for branching the releases and doing the requisite cat herding to make sure any ABI / KBI breaking changes go in before a major release is branched and any show stopper bugs are fixed before the release branch becomes a release. It has a security officer, who receives reports of security vulnerabilities, brings in experts to handle them under embargo, and handles coordinated disclosure for anything that affects other platforms (e.g. wpa_supplicant). Releases are time based. If you want a feature in FreeBSD 15, you have to make sure it’s ready in two years. If you want it in 14.1, you have to make sure you’ve added padding now to any structures you’re going to want to extend and you need to make sure it’s ready in time for 14.1 being branched. All new work goes into -CURRENT (main branch in git). Once it’s had some testing, and if it doesn’t break ABIs or KBIs, it can be merged to a -STABLE branch. There is one -STABLE branch for each major release series. A new major release is created by branching -CURRENT, followed by a period of stabilisation. A new minor release is created by branching the corresponding -STABLE branch. Security advisories and errata notices are handled by cherry picking things from the -STABLE branch into the -RELEASE branch for a given minor release. If you see a version like 12.4p6, this means that -CURRENT was branched to create the 12 release series, there have been 4 subsequent minor release branches with features moving from -CURRENT into -STABLE and then the stable branch being branched to create a release, and there have been 6 things that merited a fix more urgent than a new release and we’re cherry picked back to the release branch. The release engineer and security officer have final sign off of these activities.
The one bit of Agile that FreeBSD does is ‘people over process’. The core team accepts nominations of people to receive commit access. These people are then mentored by an existing committer and, typically after a few months, leave mentorship. If they don’t commit anything for 18 months, their commit bit is taken into safekeeping and they need to ask core for it back again. Core may then add another mentoring phase (I asked for this because I was away for a few years and that included the svn to git migration and so it’s useful to have some extra sanity checking).
Once a committer is accepted into the project, they’re treated like an adult. If they want to introduce a major new feature, they’re expected to provide design docs and drive consensus. If they want to work on an existing part of the code, they’re expected to talk to the people that currently work on it and make sure that they’re all working in, if not the same direction, at least mutually compatible directions.
OSS projects usually have one floating release property. With a fixed release cadence it’s features: whatever makes it in time (and stabilizes enough) ships. With a fixed feature schedule, it’s release dates: Things take however long it takes.
Many larger projects went for locking down the release cadence because the feature-oriented approach led to long slogs in which no releases happened, but in the past, the feature based release scheme was popular, too.
It depends on what you call “Agile”. For example, most of Scrum teams I’ve seen couldn’t be more far from the principles of The Agile Manifesto (and more far from achieving the Graal of agility, which is a vertuous fast user feedback / product enhancement loop).
So if you mean: well-defined roles, clear metrics to follow the project health, and user story estimations, then that doesn’t sound like any open-source project I follow (and that also sounds like Hell to me).
But if you mean: personal engagement, listening to users, continuous delivery, and flat collaboration, then probably many open source maintainers would recognize their work.
Of course sometimes you need someone being identified as the one who holds a specific role. But most of the time, as open source often means volunteering, the answer to “ who will do this?” is “whoever is available”. And most of the time, the answer to “ when this feature will be ready?” simply is “when it’s ready”.
Fundamentally I don’t think agile is a great fit for open source projects.
In an agile project, every engineer on a team is supposed to be able to accomplish every user story. That’s the whole point: rather than have dependencies on individuals with their own particular areas of expertise, have a cohesive team where every player can participate on equal footing. Then you can build reasonable expectations for team performance and predict the team’s progress. If one team member takes a vacation or quits or has a bad day, it doesn’t impact the overall success of a project.
In open source, typically most engineers don’t want to be interchangeable players on a production team. Whether they’re doing it as a hobby or paid by a company, open source engineers are aiming to contribute in some particular direction to extend the project to accomplish a specific goal. So the process is more like: 1) propose a change 2) write the code to accomplish that change 3) get it reviewed and checked in. That’s it. If that person isn’t available, the work doesn’t happen, and everyone’s OK with that. There is no “boss” who is mad that the work isn’t getting done.
In my experience this leads to extremely high quality, since everyone involved really wants to be there, and there’s no release pressure or deadline. On the other hand it can mean progress is slow.
This would be an interesting blog post!
No, because it is mostly not used. Agile does not really make sense in these projects.
“agile”, in the sense of the manifesto principles,
These are present a lot. Usually by letting individuals with technical knowledge owns the features, a fixed release schedule with a main branch that is always releasable, and collaboration with users and engineers over design tradeoffs to ship earlier and how it would be handled after the fact.
But that is really far from your usual Agile practices, because, quite simply, the FOSS projects do not have stakeholders, deadlines, or other department schedules to align with. They produce the features that seem useful or they want to work on.
It is a different environment in terms of resources, goals and constraints, so it generates widely different strategies to achieve them.
I don’t have a response to your question specifically, but the convention for questions on lobsters is to use the
asktag and state your question rather than trying to clarify it via discriminants in the title. You can’t edit the story now AFAIK so a mod will probably fix it themselves when they see it, but it’s good to know for the future.Hope someone with some relevant information is able to swing by and offer an actual answer soon!
“Agile” as practised in most shops is a system to (attempt to) trade throughput for predictability, by removing as much of the day-to-day difference in overall programmer abilities and detailed interest/focus areas, to make forecasting easier for bean counters.
And it doesn’t even do that all that well.
It requires an environment of corporatism and control that is anathema to open source. If you’re not paying me, I’m not coming to any of your stupid ceremony meetings.
It’s an interesting question but I don’t think it makes much sense.
Most of these projects are developed on a “work on X is done by who wants to work on X, whenever they have time”. There is usually no “team” in the sense of that they are working to have a deliverable after 2/3/8 weeks. I also don’t see a lot of sense in Kanban, especially the ‘only work on 1 thing’ - like no, this is my spare time, if I want to work on it I will, but I will not commit to a 2 week sprint, or attend any meetings.
And if you’re talking about the (imho, rare) projects with paid employees doing most of the work in an organized mode, I still think that “external” contributors do single features on their own time.
Yes, I am conflating some things here but imho that’s the majority of projects. And most of them only have 1-5 committers anyway, not necessarily being active at the same time of day/month/year.
Really appreciate all the replies!. Thank you.
I could not find OSS projects that use Agile methodology. So I thought to ask.
My initial conclusion was that ‘time/effort’ planning was not the goal of OSS projects. That was the reason why Agile was not practiced.
But as many pointed out in replies, the OSS projects attract contributors who have (or want to develop) specific skills, who have specific goals. That means that the skills & interests of the particular contributor define what they work on.
This is different for most the business settings, where programmers are expected to work areas of the code that need to be completed to meet client’s expectations, and not on what they want to work on. And that’s another import ant reason why Agile is not practiced in OSS.
The combination of those two reasons, is why planning (backlog grooming, estimates), release train engineers, product owners, scrum masters, and many other roles and sub-processes do not fit OSS projects.