Lessons learnt writing open source software
source link: https://techteapot.com/posts/lessons-learnt-writing-open-source-software/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Lessons learnt writing open source software
I don’t suppose many of you know my dirty little secret: I’m a failure. There I’ve said it. I founded an open source project and failed miserably. Sorry! Please wait there whilst I go outside to self-flagellate…that’s better the open source gods have been salved.
Back in 2005 I knew there was a tool missing from Apache for ad-hoc searches on access logs. Now, I mean a tool for performing ad-hoc searches not the programmable type. You can use AWK, a very flexible text manipulation tool, for that.
What I wanted was a tool for finding each entry in my Apache access log of all requests for a specific page or from a specific referrer. Something quick and easy without the need to learn complex commands. Quite often I find something in AWStats and I want to check it out in the raw log.
You’re probably thinking, why not just use grep? Well, grep doesn’t work very well in access logs. Say you want to find all accesses for a particular page. Greping will find all page accesses but it will also include all pages in which the page is the referrer (for images and the like referenced by the page) too. So, you will still have to sift through all of the other accesses to find what you’re looking for.
Logfilter treats each field separately so you can search on a specific field, or multiple fields.
Unfortunately, I suspect that a combination of the design goals and project scope seeded the project’s failure.
I may have been scratching my own itch, but how many others have the same one? The scratchiness of a problem is likely to be the main factor that makes a project succeed. If there is not commonality of need, then a community is unlikely to form to scratch the common itch.
The second problem comes in the form of the design goal. A tool that can be used quickly and easily without complex options necessarily limits where you can go with the tool. Every time I thought about adding a new feature I knew that the goal would be compromised because it wouldn’t have been simple to use any more.
In my experience, “open” development isn’t that much different from closed development when there’s just the one of you. Open development, when performed to an audience of one, is quite like closed development. Given two eyeballs, all bugs are deep to paraphrase Eric S Raymond. 😄
Recommend
-
14
My side project ( PigCI ) was a ruby gem that you'd attach to your RSpec test suite, and it'll warn you via a GitHub App if you had an unexpected increase in memory usage or database requ...
-
25
TL;DR: If a library module includes a flavor dimension that the app flavor does not, then use missingDimensionStrategy to specify default flavors from the missing dimension More general...
-
14
What is an inline class? An inline class is a special type of class defined in Kotlin that only has one property. At runtime, the compiler w...
-
9
News » News & Analysis » Cicada Innovations CEO Sally-Ann Williams on the best & worst of 2020, t...
-
8
10 lessons learnt from the Ruby Refactoring Kata - Tennis Game Over the last ~2 months, I’ve been scheduling some time to work on a specific Ruby code which is designed to be a good starting point for a refactoring. Those...
-
15
jueves, 25 de marzo de 202118:00 hasta el 19:00 CETEvento en líneaEnlace visible para los asistentes
-
5
News » Insights » 12 startup lessons I learnt from Seth Godin
-
8
-
3
It’s not finished by a long way, but my personal site is my first attempt at building something from scratch with no design brief or guidance to follow. A total “blank canvas”; pretty intimidating stuff! On...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK