Slashdot Mirror
Why Your Software Project Is Failing
An anonymous reader writes: At OSCON this year, Red Hat's Tom Callaway gave a talk entitled "This is Why You Fail: The Avoidable Mistakes Open Source Projects STILL Make." In 2009, Callaway was starting to work on the Chromium project—and to say it wasn't a pleasant experience was the biggest understatement Callaway made in his talk. Callaway said he likes challenges, but he felt buried by the project, and reached a point where he thought he should just quit his work. (Callaway said it's important to note that Chromium's code is not bad code; it's just a lot of code and a lot of code that Google didn't write.) This was making Callaway really frustrated, and people wanted to know what was upsetting him. Callaway wanted to be able to better explain his frustration, so he crafted this list which he called his "Points of Fail."
"he should jut quite his work"
not a lot, just a little
If we're going to talk about Callaway's Points of Fail, and create a link in the Slashdot summary that *looks* like it takes you to that list, then perhaps there should actually be a link to the list.
Callaway's original Points of Fail blog post.
You know, instead of the usual Slashdot way of pointing to an article wrapper that talks briefly about some of the points and then eventually links to the real list.
~Idarubicin
His list, instead of the link to a blog with an article about the list. That blog post is interesting - though the picture of the author scratching is just weird. Was that taken at a lice convention?
>> 1) If your codebase is too big, it's going to limit who's going to be able to download your code.
>> 2) There is no good reason in 2015 for a FOSS project to not have public source control. This helps people contribute and determine the health of your project based on the date of the last commit.
>> 3) If your source control has no web viewer and/or no documentation, these two are obvious things to have
>> 4) Code that doesn't build is worse than no code! You need documentation on how to build the project from the source.
>> 5) Use build tools
>> 6) Bundling is not going not be maintainable. Bundling leads to forking.
>> 7) Forcing people to install only in a specific directory
My first thought on reading this is that this guy started coding this year. #1-3 is solved by using GitHub, TFS online or one of the popular choices most FOSS projects already seem to use. (e.g. How would an experienced developer get these problems in the first place?) #4-6 are entry-level build issues. #7 refers to a best practice (let people pick their install directory) that's been commonplace in the industry for at least 15 years.
I see he's employed by Red Hat. Does this list as news suggest that Red Hat's internal development processes are immature too?
"How would an experienced developer get these problems in the first place?"
A lot of projects do not follow widely-accepted best practices... even if they are experienced... and that is a problem!
A remarkable number of OSS projects fail to have a public source control system (#2). That includes many established projects that everyone depends on. Actually, a number of OSS projects - and projects that people THINK are OSS but are not (because they have no license) - fail many of these points. It's not that Red Hat's internal processes are immature; Tom was trying to bring in software from someone else (Google in this case) and was fed up by the poor practices from people who should know better.
Yes, #7 refers to a best practice (let people pick their install directory) that's been around for at least 20 years and probably much longer, but it's still widely NOT followed.
Anyway, that's Tom's point; there are a lot of widely-accepted best practices that are NOT followed, and that needs to change.
- David A. Wheeler (see my Secure Programming HOWTO)
As a software dev for closed source, our problems are creeping into open source at an alarming rate. Standups, Kanban, Scrum, swim lanes, and other political middle management bullshit is making it harder and harder to as theo de raadt once said, "shut up and hack."
The other issue is runaway devs. Gnome and KDE turned into piss pots almost overnight because they followed lockstep with whatever was trending. gnome grew hotspots that were clickable and draggable in an attempt to appeal to tablets, and KDE's widget framework turned into a swirling vortex of lights and colours that chewed through ram like none other. And the "fuck it lets move on" mentality has got to stop. Pottering epitomizes the swinging dick Linus so rightly kicked after his team was called out for set it and forget it code that ultimately broke more things and didnt play nice.
bottom line: dont lose focus in stability and function.
Good people go to bed earlier.
It depends a lot on the codebase. Codebases tend to accumulate cruft. Having people refactor them because their requirements are different to yours can help, as can having a project developed without key product ship dates as the driving force. The bigger barrier is culture though. It's really hard to have a group of developers that have been working on a project for 10 years in private move to developing in public. In the list, he actually gives different numbers of fail points, more for projects that were proprietary for longer than they were open, which makes a lot more sense than the summary in the 'article'.
The one that I disagree with is 'Your source builds using something that isn't GNU Make [ +10 points of FAIL ]'. I disagree for two reasons. The first is that it implies using GNU make features, which likely means that you're conflating building and build configuration (which should gain some fail points). The projects that I most enjoy hacking on use CMake and Ninja for building by default (CMake can also emit POSIX Makefiles that GNU Make can use, but I take his point to mean that gmake is the only command you need to build, so the CMake dependency would be a problem). LLVM still more or less maintains two build systems, though the autoconf + gmake one is slowly being removed in favour of the CMake one. If I make a small change, it takes Ninja less time to rebuild it than it takes gmake to work out that it has nothing to do if I don't make any changes.
I'd also disagree with 'Your code doesn't have a changelog' - this is a GNU requirement, but one that dates back to before CVS was widely deployed. The revision control logs now fill the same requirement, though you should have something documenting large user-visible changes.
I am TheRaven on Soylent News
"editing flat text config files"
All while working for RedHat. RPM relies on shell scripts and doesn't have a reliable rollback/commit mechanism.
Is it just the slam against "Microsoft Visual Anything"?
But yeah, this obvious attempt at slamming business competition under the guise of technical know-how is oh, so 1995 (which was 20 years ago). But, in todays world, we have gotten to the point when it is not only easier, but more reliable to generate code than to write it by hand. And while they have some learning curve, visual code analysis tool are still better than text-only ones. Even the resurgence of C can be mostly attributed to the fact it's simpler syntax makes it easier to generate than the new C++ syntax.
Any guest worker system is indistinguishable from indentured servitude.
"You've written your own source control for this code [ +30 points of FAIL ]"
What do you mean "locked to a single platform". I admit that I haven't tried it, but they give away the source code to VS 2015. Which is pretty much why RedHat it trying to claim that code which used to be owned by a single company is a point of failure. It's another business swipe at MS. RedHat is running for the hills because pretty soon they'll lose all purpose.
Any guest worker system is indistinguishable from indentured servitude.
People start projects because they want to create something cool, not because they want to be project managers. But if they don't manage the project it fails.
And not just software. Look at security as well. And so many other computer-related areas.
For me it's more like ... someone "learned" one way of handing it when s/he was working ALONE.
Then that person never learned that the practices need to be changed when you are part of a TEAM.
And releasing your code to the public is being part of a team.
this a slow news day? The list was crafted in 2009!
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel