Reaching 100 stars on GitHub: what I learned from putting code online

When the pandemic started in early 2020, I needed something to get my mind off things. Frustrated with most database form generation solutions I created Cruddiy and put it on GitHub.

Two years later Cruddiy reached 100 stars on GitHub. Something which I did not expect.

We could argue a long time on what a GitHub star as a metric actually represents, but for this post it represents: hey, more than one person had a need for this thing.

Cruddiy is a small collection of PHP files that you point to your MySQL/MariaDB database and you run it (usually) just once and after a few steps/questions — no coding required — it will generate a set of pretty good looking PHP forms for you — usually one per table. The generated forms have basic CRUD functionality, search, pagination and sorting. The forms are based on Bootstrap and you have seen these forms a million times before. You can use them as they are, or use them as a starting point i.e. scaffolding to further improve on (coding required). And here’s the good part: you can delete Cruddiy when you’re done.

Simple?

Most developers reading this will probably now scream say: hey, but you can use framework X or framework Y! And yes, this is true and I have used and done all of that. But I do not like installing a ton of dependencies to generate just a few simple PHP files (which they are): and this is more or less always the case. Read the original post for more background.

So Cruddiy is my attempt to keep things as simple as possible.

I am allergic to pulling in lots of files and folders that clutter my system, especially when I don’t know what all these files do. So Cruddiy does not use Composer, Laravel, Symfony, Docker, or other dependencies. Nothing of the sort. It’s just plain PHP files, that generate other PHP files.

Cruddiy was created to scratch my own itch, and I have used it several times since. But judging by the number of GitHub stars and comments and thank yous I received I think it’s an itch for more people. Part of the reason I put it on GitHub is because I spent more time on it than was probably warranted, and I wanted an excuse to warrant the invested time. Cue famous XKCD comic:

So putting the code on GitHub is a way to shave more time off — other people’s time, but still: time.

Also another XKCD comic comes to mind:

Cruddiy is a small project in every sense — in lines of code, number of commits, number of contributors, and number of GitHub stars –, but still, through Cruddiy I experienced the magic of people on the other side of the world, finding and using something I created. The internet is amazing.

Here are some things that I picked up by putting things out there.

1. Opinions

Everyone has one, right? I was excited when I received the first patches from a complete stranger and pulled them in, thinking how amazing this was. However this person was very opinionated how things should work, which bothered me a bit. And he talked to me like I worked for him. But I didn’t pay too much attention to it, I thought maybe this is how it works?

But when Cruddiy stopped working correctly and had some other weird bugs I removed most of his code and decided: you can fork Cruddiy however you please, but this codebase here is how I want things. And there is absolutely no obligation for me to pull in your code, especially code that fundamentally changes how things work. (It still bothers me a bit that he proposed to move the code to a different folder. I might still revert this).

It was a hard lesson because I had already developed a bit more based on his code so reverting wasn’t very straightforward and involved some Git tricks that I never want to use again.

I still find it weird, that I just blindly trusted someone and his opinion purely because I was so surprised that other people had an actual use for Cruddiy. But if I had kept at it Cruddiy would have probably withered (being broken and all) and ended up being unusable.

One of the key takeaways here is: something might be open source but you still need people to take care of it e.g. make important decisions for it, it will not survive on its own because there are too many opinions out there. And preferably that person should be you. This is true for arguably the biggest distributed software project in the world — Linux — right down to a very small project like Cruddiy.

That being said, the above example was of someone being opinionated i.e. rude. But a lot of people seem to have a strange way of asking for things. Please spend some of your valuable time fixing this and that for me, kthxbye.

2. Audience

Judging by the level of questions and requests I receive, I noticed the average Cruddiy user isn’t a computer programmer.

And this is expected, since Cruddiy is a no-code solution.

I do however find it somewhat baffling that there are people who find their way around GitHub without either having a decent understanding of code or Git/GitHub.

Case in point: I had contact with someone who had good ideas — and who sent me actual codepatches, which I merged. But this person did not know how to use git or GitHub. Which is … surprising, to say the least!

This person also asked if I had a Discord server (!?) which he found easier to communicate by than e-mail.

This tells me a couple of things:

1. GitHub is much more than a code sharing site, it’s also where people go for solutions sans Google.
2. There is still so much to win for GitHub, it’s not simple enough yet. Make it simpler to use and more people will use it.
3. Discord is successfully replacing e-mail for some people.

3. Licensing

I started Cruddiy under GPL2, because, well why not? Lots of projects use GPL2.

However I did some reading and switched to AGPL-3.0 License, I think it is important to share changes. However: I was and am still not sure if Cruddiy fits the AGPL bill: is it really a networked piece of code (isn’t everything on GitHub in a sense a piece of networked code)?

I am no license expert, and might be wrong about this interpretation but I see AGPL-3.0 as GPL3.0 with an add-on.

The lesson is: think about what license your code should have before putting it out it online.

4. Releases

This was one of the more surprising learnings. Usually when I pull code myself from GitHub I always look for the latest commit. But this is not normal?

Early on I created some tags and based one or two releases on these tags. Just to play around with tags and releases. It wasn’t until later when a user had some weird errors that I found he was using a very old release. Why? Because it was the only release available and that is were people look! Duh…

So now I make it a habit to tag commits and release the tag.

5. GitHub quirks

There are two:

1. This is a possible GitHub caching thing, but I noticed I always get a flurry of stars, then weeks nothing, then again a flurry of stars. Nothing particular about this, just strange behavior that might have something to do with caching.
2. I have NO idea how people find Cruddiy: there is no Google analytics. Do they find my blog first and then GitHub or the other way around? I would have like a bit more insight into this.

6. Energy

Most of the work I put in Cruddiy was at the start (a good chunk of my evenings for a couple of weeks). The project is still only 60 commits old (again; very small). There are many more ideas Cruddiy *could* do, but which *I* don’t need now. So this means things stay mostly as they are.

I notice when people point out bugs: I am driven to fix these. But pro-actively sitting down and adding new features is not something I do. I maybe could, but I don’t. I need a real use-case for it. Last week I added a navbar solution, which greatly improves the visual of Cruddiy, but this was only because someone showed me he hacked a navbar on top of Cruddiy, which drove me to incorporate it in Cruddiy that same evening.

7. Looking at your own code

I am not a professional developer. That is not my day job. So most software projects I embark on are either small or ephemeral. Cruddiy however has forced me to look at code that I wrote up to two years ago, and yes everything they say about writing clear code is true. Here is what I found:

1. Don’t try to be clever, first and foremost: make it clear. So future you might understand what it is you were trying to do.
2. Write code as if you’re explaining to someone else (again: that someone else is future you).
3. Don’t think you don’t need to comment code because it makes sense by itself: comment code!
4. Less lines of code is not always better. Do not trade clearness for conciseness.

Putting code out there

I do not feel obliged (anymore) to adhere to every wish out there. But I do want things to work as I promised. So I have to admit it also gives me a bit of anxiety when people have errors or bugs and I can’t take over their keyboard, I have to guess at their config/setup, which bothers me a bit. Just as it bothers me when I try and help people and never hear from them again.

Also I don’t think I have become a better developer, if anything it may have been detrimental to my skills: since wanting to fix things quickly doesn’t necessarily produce the best code.

But these are all minor inconveniences. They do not weigh up to the sheer enjoyment I get from the idea that someone, somewhere out there is using something I made to help solve a problem.

So if you have the choice: put your code out there!