Why Balanced is an open company(fastcolabs.com)
fastcolabs.com
Why Balanced is an open company
http://www.fastcolabs.com/3008944/open-company/why-i-made-my-payments-startup-an-open-company
3 comments
Here's a few counter-examples of easily fixable bugs in closed systems that really bug me.
GitHub has a few tiny bugs that could probably be fixed with a few lines of code within a day (best case scenario), but they haven't for months now since I've reported these issues. http://shurcool.github.io/bettertogether/
The latest version of Chrome for iOS has a shadow not appearing properly when you open a new tab in the background. Once you switch to it, it's fine.
Chrome [1] for OS X has a small area around the close tab button where the hover animation occurs (button highlights red), yet clicking the mouse does nothing. You have to move the cursor a few pixels closer to the center before clicking will have an effect. This discrepancy between hover and clicking action is annoying because I often (several times per day) run into it. OS X dock has a similar issue.
I'm very picky when it comes to the smallest details... I'd rather fix them and move on than keep running into them every day.
[1] I know this one is open source, but because it's a huge project, I never got around to compile it, etc.
GitHub has a few tiny bugs that could probably be fixed with a few lines of code within a day (best case scenario), but they haven't for months now since I've reported these issues. http://shurcool.github.io/bettertogether/
The latest version of Chrome for iOS has a shadow not appearing properly when you open a new tab in the background. Once you switch to it, it's fine.
Chrome [1] for OS X has a small area around the close tab button where the hover animation occurs (button highlights red), yet clicking the mouse does nothing. You have to move the cursor a few pixels closer to the center before clicking will have an effect. This discrepancy between hover and clicking action is annoying because I often (several times per day) run into it. OS X dock has a similar issue.
I'm very picky when it comes to the smallest details... I'd rather fix them and move on than keep running into them every day.
[1] I know this one is open source, but because it's a huge project, I never got around to compile it, etc.
pull requests welcome and much appreciated ;-)
https://github.com/balanced/balanced.github.com/issues
https://github.com/balanced/balanced-dashboard/issues
you just reminded me of a mobile display issue on the blog: https://github.com/balanced/balanced.github.com/issues/32
you just reminded me of a mobile display issue on the blog: https://github.com/balanced/balanced.github.com/issues/32
The Chrome example brings up a good point: it's a lot easier to fix niggling details on small projects than big ones. We could probably stand to see some innovation in architecting open products to be easy to install only part of into a development environment. The GitHub editing interface helps here, though project culture is another barrier. I fixed a typo on AngularJS and started to discover a heavier project structure than I'm used to:
https://github.com/angular/angular.js/pull/2374
Maintaining a culture of innovation at scale is a challenge for both open and closed companies.
https://github.com/angular/angular.js/pull/2374
Maintaining a culture of innovation at scale is a challenge for both open and closed companies.
I absolutely agree. I think we need to try to innovate how large scale complex software can be written.
One of the approaches I'm currently investigating and have high hopes for composition, pure functions, and explicit two-way dependency tracking. I'm trying to put this to the test in my work. The idea is that I hope even huge software can be decomposed into smaller independent (meaning all the dependencies are explicit) chunks with pre- and post-conditions. So fixing many bugs could boil down to navigating to the code responsible and fixing it there. It's too early for me to say how it'll work in reality, but I will find out with time.
One of the approaches I'm currently investigating and have high hopes for composition, pure functions, and explicit two-way dependency tracking. I'm trying to put this to the test in my work. The idea is that I hope even huge software can be decomposed into smaller independent (meaning all the dependencies are explicit) chunks with pre- and post-conditions. So fixing many bugs could boil down to navigating to the code responsible and fixing it there. It's too early for me to say how it'll work in reality, but I will find out with time.
I have done this with blog posts by Balanced, actually. Especially with 'edit this file on GitHub,' it's so simple.
In my experience, the only nicer UI for fixing typos is Medium.
Here are some examples of where I was able to do just that. It's tiny things, but it feels great to make something better.
https://github.com/liveprogramming/2013/pull/1/files
https://github.com/liveprogramming/2013/pull/2/files
https://github.com/skx/bookmarks.public/pull/1/files
https://github.com/gittip/www.gittip.com/pull/625/files
https://github.com/mojombo/semver.org/pull/55/files
https://github.com/liveprogramming/2013/pull/1/files
https://github.com/liveprogramming/2013/pull/2/files
https://github.com/skx/bookmarks.public/pull/1/files
https://github.com/gittip/www.gittip.com/pull/625/files
https://github.com/mojombo/semver.org/pull/55/files
Much of the frontend for the blog was done by github.com/joonas (not a Balanced employee): https://github.com/balanced/balanced.github.com/pull/3
We're working on the same approach at FastCompany--we've already started loading all our Labs posts into github, and soon we'll allow readers to fork articles to correct them, argue with them, edit or create their own versions. Github obviously wasn't meant for dealing with rich text articles, so it's taking some hacking, but we agree that it's a positive experiment. --chris dannen, tech editor, fastcompany
"ever a spot" -> "ever spot"
<:)
<:)
HN comments should have pull requests.
They totally should. Everything should. There's no reason to make them not available.
#winning
Open isn't an on/off switch. Open is a slider.
There are varying degrees to which you should expose your inner workings. Some of it may be intriguing for investors to be comfortable enough to throw money at you knowing you'll turn a profit. Some of it would be enticing for your customers who can see whether you've got your act together.
But this "Open" as a buzzword is something we have to be careful with. Transparency can be good for business, but only within reason. Also, be careful of how much tint you use on those rose colored glasses. It's not that you present the truth; it's how you go about doing it.
There are varying degrees to which you should expose your inner workings. Some of it may be intriguing for investors to be comfortable enough to throw money at you knowing you'll turn a profit. Some of it would be enticing for your customers who can see whether you've got your act together.
But this "Open" as a buzzword is something we have to be careful with. Transparency can be good for business, but only within reason. Also, be careful of how much tint you use on those rose colored glasses. It's not that you present the truth; it's how you go about doing it.
I find the topic really interesting. However it is the first time I see that Balanced is involved in this vision. From their homepage, I don't see any link about their openness. What did I miss ?
It's been about 9 months now that Balanced started the approach towards openness: https://github.com/balanced/balanced-api/issues?direction=as...
Building an open company wasn't part of the initial vision. It's something that we've embraced as we grow Balanced.
Regarding the homepage, that's a great suggestion.
Building an open company wasn't part of the initial vision. It's something that we've embraced as we grow Balanced.
Regarding the homepage, that's a great suggestion.
That's the kind of future I want to live in. I'm very thankful to Balanced, Gittip for being some of the ones paving the way there.