How many times have you looked at someone’s code and stated:
I’m not using this because it doesn’t look well-written.
And in this case, “look well-written” might either be a substitute for:
“look like how I would write it,”
“seem to make sense to me.”
Sure – there are times where using open source code is risky. We know this from the various software and services that show up with vulnerabilities. But, at least for this post, treat those as the exception – not the rule.
This means we’re left with looking at something we may use but opt not to use because it doesn’t seem to be written in a way that we think it should be written.
Depending on your history with working source control, the way in which you go about working with a codebase, making commits, etc., varies.
Further, depending on if you’re using Git, Subversion, Mercurial, and so on also dictate how you manage your code.
But if you’re someone who’s working with Git (which I know many people in WordPress are starting to use more and more almost on a daily basis), there are some small things that I recommend doing to help make managing changes espcially with a team more manageable.
The other day, I was talking with a friend, Toby, about the lack of inactivity I have on GitHub. Specifically, I have a lot of private repositories, and I have a lot of secret gists. There’s a method to all of this that I follow, though:
private repositories are typically dedicated to client projects or projects that I don’t think are ready for others to use yet (for the sake of the overhead in managing it),
gists are strictly for sharing code snippets on this blog, and that’s it,
open-source WordPress libraries are occasionally there but have become quite dated,
That is, I don’t really open-source my WordPress libraries. I have reasons for this all, but the bottom-line is that I want to change that.
I’d like to think that one of the struggles many developers feel when shipping code is a sense of “this could be better” before they push whatever button to send their code out into the world.
It doesn’t necessarily matter if this is a hobby project, if this is a project for a corporate job, a freelance job, or if this is something that’s for an open source project. I say that because I think this is something that many of us feel with whatever it is that we release.
It’s a feeling of something is “not quite done” or “if I could just refine this a little bit more.” I know: This isn’t the first time I’ve talked about this before, and it’s likely not going to be the last.
And the feeling is not without merit. Other developers can make us feel like we’re doing something wrong (sometimes we are, sometimes we aren’t). But in our industry, I think there’s more of a spectrum of optimal-to-suboptimal. Though some may not agree, a friend of mine recently said it best:
The software industry is too vast and too fast to keep up with it all. But because it’s now that way, people find their niches and think that it’s the “best” or “only” way to get something done.
The further I get into my career, the more I feel this sense of obligation to make things as pristine as possible before sending it to a client, user, or just out for the world to use.
And though I think this is important, it’s important to make sure that I (and we) are doing this for the right reasons.
An example of a wrong reason might go something like this:
It’s not because it doesn’t meet requirements and it’s not because it doesn’t fulfill what was requested by the client. It’s because how others might perceive the work when they do not have the proper context.
So of course, I don’t think there’s anything wrong with wanting to make your code base or your architecture as robust as possible. We should all strive for that. But I believe that it’s important to contextualize appropriately and adequately scope your sprints, milestones, work or however you group your tasks together.
To me, one of the most interesting aspects of open source culture is the variations in open source philosophy we all have.
By that, I mean though many of us appreciate what open source has done, we have varying degrees on how much we use it. For example, some people use only open source software. On the other side of the spectrum, some people never use open source software.
Then, as expected, there are a lot of things that sit between these two points. You know: The proverbial gray area.
As of last week, an interest article has been making the rounds about Slack and FOSS projects. I’ll talk about it more in a moment.
But first, since I’ve never written about my own perspective on open source, I thought I might as well try it.