5 Ideas for an Enhanced GitHub Workflow Working with source control in general can be made easier with a solid workflow.

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.

Continue reading5 Ideas for an Enhanced GitHub Workflow Working with source control in general can be made easier with a solid workflow.

Open-Source WordPress Libraries (Why I Should Share Them)

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,

But during the conversation, I came to the realization that I have a lot of small classes, plugins, utilities, functions, helpers, etc. related to WordPress development or JavaScript that I’ve never really put on GitHub.

Open-Source WordPress Libraries: Where Are They?
Much of what I currently have is out-of-date.

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.

Continue reading “Open-Source WordPress Libraries (Why I Should Share Them)”

Your Source Code (“This Could Be Better”)

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.

This Could Be Better: Code Review This
Yeah, okay, code review this.

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.

Continue reading “Your Source Code (“This Could Be Better”)”

The Spectrum of Open Source Philosophy

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.

Continue reading “The Spectrum of Open Source Philosophy”

The Challenges of Monetizing Open Source Software: Contributors

The very idea of monetizing open source software – especially projects that have a list of contributors – is something that I spend more time thinking about than I’d like to admit.

One of the many Dev Practices
One of the many Dev Practices

And I bring this up because there are a number of things that I’m working on (and that I’ve seen my peers work on), that are directly impacted by this.

As with anything, I’ve my own opinions about this, but I’m curious as to what you guys think as it relates to monetizing open source software.

Continue reading “The Challenges of Monetizing Open Source Software: Contributors”