Four years ago, I wrote an entire version-control system in a 14-hour burst of inspiration. It’s a small, lightweight tool designed for solo single-file projects that allows several histories to coexist in a single directory – good for /etc files, HOWTOs, or that script collection in your ~/bin directory.
I wasn’t certain, at the time, that the concept would prove out as a production tool for anyone but me. But it did. Here are some statistics: Over 4 years, 21 point releases, 644 commits, 11 committers. Six issues filed by five different users, 20 merge requests. I know of about half a dozen users who’ve raised their hands on IRC or in blog comments. Code has about quintupled in size from the first alpha release (0.1, 513 lines) to 2757 lines today.
That is the statistical profile of a modest success – in fact the developer roster is larger than I realized before I went back through the logs. The main thing looking at the history reveals is that there’s a user community out there that has been sending a steady trickle of minor bug reports and enhancement requests over the whole life of the project. This is a lot more encouraging than dead air would be.
Of course I don’t now how many total users SRC has. But we can base a guess on fanout patterns observed when other projects (usually much larger ones) have done polls to try to measure userbase size. A sound extrapolation would be somewhere between one and two orders of magnitude more than have made themselves visible – so, somewhere between about 200 and 2000.
(There seems to be something like an exponential scaling law at work here. For random open source project X old enough to have passed the sudden-infant-death filter, if there’s an identifiable core dev group in the single-digit range you can generally expect the casual contributors to be about 10x more and the userbase to be at least 100x more.)
SRC has held up pretty well as a design exercise, too. I’ve had complaints about minor bugs in the UI, but nobody bitching about the UI itself. Credit to the Subversion developers I swiped most of the UI design from; their data model may be obsolete, but nobody in VCS-land has done better at UI and I was at least smart enough not to try.
2.7KLOC is nicely compact for an entire version-control system supporting both RCS and SCCS back ends. I don’t expect it to get much larger; there are only two minor items left on the to-do list, neither of which should add significant lines of code.
Today I’m shipping 1.21. With gratitude to everyone that helped improve it.
FYI src will soon be entering Debian (as simple-revision-control).
Whatever tool you used to generate the NEWS file for SRC put the wrong date; hopefully it should be pulling the date from the version tag in the repo, no?
I haven’t made any contributions to SRC, but I’m one of the maintainers of it on NixOS; I found a bug in the packaging and fixed it, plus a couple of version bumps (early last year).
I’d update it now (it’s currently 1.17), but I rejoined for $COMPANY in late March after about a year off for school, and they still don’t have an official policy re: open source contributions (except that company approval is required). I’ve been pushing as much as I can (including writing a draft of what I thought it should look like, but IANAL), so maybe before the end of the year…
>Whatever tool you used to generate the NEWS file for SRC put the wrong date; hopefully it should be pulling the date from the version tag in the repo, no?
Alas, that was a manual fuckup. and one I’m annoyingly prone to – cutting/pasting and then forgetting to correct the month/day when I bump the version. I should upgrade shipper to sanity-check this. I think I’ll do that now.
Why would you be manually doing this? Doesn’t it make sense that the build process would simply make the NEWS date be equal to the timestamp of the most-recently-modified source file in the project?
I assume SRC is used to maintain SRC sources, so maybe this is a job SRC itself should do. Then it’s just a matter of uploading the thing to the website, but I’m sure that’s part of your
publishscript by now.>Doesn’t it make sense that the build process would simply make the NEWS date be equal to the timestamp of the most-recently-modified source file in the project?
It might, but editing NEWS files is tricky as the format is not very well or consistently structured.
>I assume SRC is used to maintain SRC sources
Oh hell no. src is a multi-file project (there’s a manual page and a test script) so it needs changesets.
>maybe this is a job SRC itself should do.
Again, oh hell no. It’s a simple minimal VCS, not a release manager that ought to know about things like NEWS format.
The right place for this is as a sanity check in my publishing script, shipper. It now looks for the topmost YYYY-MM-DD string in a plausible section of NEWS and complains if it’s not today.
Thanks to you and all the contributors. This is a tool that I use every damn day and has always worked flawlessly. Great example of product:market fit. :)
ISTM that it would be a useful feature in a FOSS product for installation of the product (or first actual use) to generate an e-mail notice to the developer group. This could be (should be) optional, and carry no private information.
This would give the developers some idea of how big the user population is.
Another feature that might also be useful, though more problematic, would be a counter that tracks uses of an installation of the product and notifies the developer group every 100 or 1,000 uses.
This would give the developers information on how much the product is actually used.
>ISTM that it would be a useful feature in a FOSS product for installation of the product (or first actual use) to generate an e-mail notice to the developer group. This could be (should be) optional, and carry no private information.
This is often contemplated but almost never done. Reasons:
(1) There’s a strong norm against anything that resembles snooping on users.
(2) The code to ship notifications feels like unpleasant extra weight. Also you have to track when not to send them, which means scribbling an otherwise-pointless mark on the user’s filesystem somewhere. Ugh.
(3) Not wise to assume the registration address will be valid forever. If it’s not, users get backscatter from mail they didn’t know they were sending. Double ugh.
Indeed. Funny that Rich should mention this as a benefit because he’s far from alone. Some open-source products from major companies come with telemetry enabled. In fact, one of the reasons why I still stick with Emacs, as opposed to migrating my workflows to Visual Studio Code, is because — for all his faults, including his 1970s outlook on architecture, workflow, and usability — I trust Stallman not to put that shit in his programs. Sure, Atom and VSCode let you disable the telemetry — but it’s opt-out, not opt-in. And companies strongly aligned with the Blight (including Google and Microsoft) tend to remove their opt-out options over time.
Yeah, that kind of “feature” is a good way to tick off your user base. It certainly annoys me.
The first version of spell(1) mailed a copy of its output to Doug McIlroy every time it was run. I doubt it went to any trouble to anonymize that output, either.
I use SRC for my personal little 3d printing projects in OpenSCAD, and I taught it in my Uni course on open source software, as an OSS example, and as a different VCS from git.
Thank you!
I’m using SRC, and I have a bug report. I’m being really lazy, and just dumping it here:
Attempting to commit without having RCS installed, results in an unhelpful error message. Confirmed in 1.18 (latest available tarball when I checked).
b@Cord:~/bin$ ./src-1.18/src commit beer
src: rcs -q -U -kb -i beer </dev/null && mv beer,v .src returned 127.
I haven’t checked in the latest, but ‘Recent Changes’ suggests the bug still exists.
Bug can occur ’cause of new computer + new OS, and not having installed RCS through apt yet (but SRC exists in ~/bin).
>Confirmed in 1.18 (latest available tarball when I checked).
That’s peculiar. 1.18 was three releases and eight months ago. You’re getting stale tarballs from somewhere.
As of version 20 you’d get a more helpful message.
I would have got it from your website some time in October, which according to the NEWS file up currently, tells me it was current until 1.19: 2018-10-27. So only a month out of date :)
I just hadn’t got around to complaining about the issue until you posted just this post.
Considering that it doesn’t bother me (now that I’ve got RCS installed), I’m going to continue living up to my name, and not get the latest version until I have to. ‘Cause 1.13 did everything I wanted, and 1.18 certainly does as well.
>(There seems to be something like an exponential scaling law at work here. For random open source project X old enough to have passed the sudden-infant-death filter, if there’s an identifiable core dev group in the single-digit range you can generally expect the casual contributors to be about 10x more and the userbase to be at least 100x more.)
Well, maybe you can generally expect that, but that is certainly not the case on my project, Wograld. Wograld, in spite of twelve years running (granted we did have some dormant periods) still only has two main contributors and no one else. I can think of several possible reasons for that, but go ahead take a look and see for yourself.