search

open-organization / open-org-definition

Working definition of open organizations
Other
59 stars 14 forks source link

Open orgs around proprietary products. #6

Closed groteworld closed 6 years ago

groteworld commented 7 years ago

FOREWORD: This probably isn't in the right repo, but I'm asking for clarification and/or guidance on the definition of an open org.

So I'm doing the brain exercises of planning out a new business. While thinking about management and operations, I've been doing a lot of soul-searching around the 5 pillars of open organizations, and from a leadership standpoint, I really enjoy the overall feel and benefits. The only issue I have is dealing with a proprietary software product that is the core of the business.

Issue: Open sourcing the code would jeopardize the business.

Earnings:

At least through the methods of making a profit that I can think of with OSS.

It is a semi-seasonal, recreation-based, consumer app, which prevents:

Competition:

The market for this app already has some big players. I have fears of opening up the codebase to those people and giving them the solutions they need. To play my own devil's advocate, my plan would be to have an open issue/feature tracker to the codebase, so competitors would be able to, if so inclined, know what new features we were planning. My answer to that argument is that plans for features and a functioning code-bite are two totally different things.

Inclusivity (or more the lack of if closed sourced)

If I don't open source and allow for contributions to the source code, I feel I have hindering end-users ability to contribute. With a proprietary application, I would want to vet people through a typical hiring process, and that makes my clear path to contributing code, "just wait till we are hiring and apply". And that doesn't feel fully inclusive, but maybe i'm making it something it's not

How do I plan on achieving an open org with a big secret?

My hope would be to open source and make public everything that we could. Our employee handbook, the marketing website, our API endpoints, the issue tracker, our documentation, our salaries, our chatroom, our internal reporting structure, our expenses, our database models, our beta releases. What would be left out of public view would be our API and App source code.

I believe my plan hits all 5 categories of an open org in one way or another, but does the closed source aspect, extremely hinder this mentality.

Thank you in advance for any help!

chadwhitacre commented 7 years ago

Thanks for joining us here, @groteworld! The general pattern that recommends itself to me is having an "open by default" policy, with explicit exceptions for closed parts of the organization. Blacklist instead of whitelist, in other words. Opening your handbook is a good place to start (I'm working up a handbook roundup, if you're interested and/or have pointers!), because that gives you a natural place to at least openly document the closed parts, if that makes sense.

As far as closed vs. open hiring goes, there's more to life a business than code. ;-) Are there functions of the business that you could make open to outsiders, with a path towards greater inclusion and crossing the threshold from outsider to insider? Perhaps a customer support forum that engaged your power users?

What is your plan for monetization, by the way? Will you charge for the app? Or will the app be free with in-app purchases? Or ads? Or ... ?

arob98 commented 7 years ago

There are companies that have aspects of their deliverables that are proprietary yet move to a more open contribution model. For example, transparency re: delivering technical content, collaborating with partners, deciding what goes into the next update, responding to question.

semioticrobotic commented 7 years ago

Apropo this issue, @groteworld, here's a new article from Opensource.com that addresses this very issue.

groteworld commented 7 years ago

@samuelknuth thanks for passing this along, I think an interesting idea brought forward by Richard is the fact that my code base, doesn't really need to be up-to-date, but could hold older versions, which would incentives users to pay for the service to have the newest features.