Why I run my business like an open source project (2013)(stubbornella.org)
stubbornella.org
Why I run my business like an open source project (2013)
http://www.stubbornella.org/content/2013/02/26/why-i-run-my-business-like-an-open-source-project/
4 comments
This article is both great at explaining an effective way of operating a business/client relationship & unrelated to it's title.
My customers usually don't look at the code I wrote, only at the pixels on the screen. Some of them even make me use their repositories but I think that in the last few years there was only one quick code review, after a customer got bought by another company. Nevertheless I keep writing tests and all the right stuff because they make my job easier.
During my years as freelancer I also rarely had a client look at the code although they had access to it. But I can imagine with some tech-savvy customers there is a lot of value in using Github.
I wish it was easier to convince companies or people you contract with to allow you to do this.
I think a lot of people could save time and money by everyone pooling efforts to build business tools that we all need.
It also takes us back to the roots of software development. Buy programmers, not software.
I think a lot of people could save time and money by everyone pooling efforts to build business tools that we all need.
It also takes us back to the roots of software development. Buy programmers, not software.
I don't think the author uses public repositories, they just use git(hub) collaboratively amongst their team and involve the client in decision making.
I certainly didn't get the impression that what they're producing is actually OSS.
I certainly didn't get the impression that what they're producing is actually OSS.
I think that there are various scales of "open-source"-ness, and these scales are moderately aligned with the abstraction layers inherent in the platform-in-use.
Its quite possible to share your source code with your client, who runs it, completely openly. In fact, this is a successful model for countless decades in certain software markets, as well as a standard model of behavior, in general, in software industry.
The way it worked is, you're a programmer->you write source code->the business paying you to write source code builds your code->they run it->customer.
However, this facet, like all other facets in the big gem of our forever-changing industry, is not as prevalent in certain software markets - for example, web&etc. There are still plenty of software developers who are in fact sharing the source - directly with their customers. As per any one of a scale of licenses.
tl;dr - please don't conflate 'open source' with 'F/OSS', et al. If your customer owns the sources, you've opened your sources to them. This is a scale, not absolute, as other ends of the scale include closed-source business models.
Its quite possible to share your source code with your client, who runs it, completely openly. In fact, this is a successful model for countless decades in certain software markets, as well as a standard model of behavior, in general, in software industry.
The way it worked is, you're a programmer->you write source code->the business paying you to write source code builds your code->they run it->customer.
However, this facet, like all other facets in the big gem of our forever-changing industry, is not as prevalent in certain software markets - for example, web&etc. There are still plenty of software developers who are in fact sharing the source - directly with their customers. As per any one of a scale of licenses.
tl;dr - please don't conflate 'open source' with 'F/OSS', et al. If your customer owns the sources, you've opened your sources to them. This is a scale, not absolute, as other ends of the scale include closed-source business models.
Does a code become "open" once I've "opened" it to someone? I don't think so.
What you're describing sounds more like https://en.wikipedia.org/wiki/Shared_source.
What you're describing sounds more like https://en.wikipedia.org/wiki/Shared_source.
Can you give me some examples where this conflation produces a confusing meaning? I'm not familiar with people using the word 'open' in this context to mean anything other than free access (with varying limits and obligations on use and redistribution).
I always offer/encourage my clients to look through the repository like the article says, but people never want any part of it. They are usually taken back.
In my experience (mostly small business) there's a certain expectation that developers will work in isolation—where clients aren't expecting any involvement beyond the initial planning stages.
In my experience (mostly small business) there's a certain expectation that developers will work in isolation—where clients aren't expecting any involvement beyond the initial planning stages.
The worst engineering behavior I've found is when development teams are not accountable for their code quality. Just a group of people developing in isolation, with code that will be never seen by anyone else. Then the code base becomes a ponzi scheme of technical debt, where a hierarchy of power is built by forcing other people to refactor lousy code.
I think auditing code for bad practices, beyond code review, is something done regularly for open source projects but very rarely on proprietary software.
Auditing, beyond code review, is key to code quality. Also, making people KNOW their code will be read at any moment by any person gives lousy developers a sense of vulnerability and a call to action to act as real engineers.