How can I open-source my software project and keep control? [closed]_问答_开发者

Closed. This question is off-topic. It is not currently accepting answers.

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 10 years ago.

Improve this question

As many of us do, I have lots of software ideas, a couple of really good ones, and not enough time to do everything. (I am a developer, but only one). I would like to open source some software and ideas in progress but also retain direction and vision of the project. Up until now I've only worked in non-free-as-in-beer software and it escapes me how open source could meet my need for control of it.

Let me be clear I don't intend to commercialize open-开发者_运维技巧sourced projects for money. That much I know. I just want to have control of my vision which I start.

To control my own open source project I would need to manage it by providing guidance but that facet escapes me also, about how to manage something that's effectively free.

Am I barking up the wrong tree?

I've gone through this cycle myself, and can tell you you're way out in front of the horse with the cart. Not to sound harsh, but there's a frame of reference you should definitely gain.

First, "control my own open source project" -- is conflicting. Open Source involves giving something away, in this case to a community. So, thinking about control and ownership of something you've given away is a mental hurdle you need to cross.

Second, you need someone other than yourself willing to participate in your project. Without them, you won't have anyone to divert any direction and vision you might have.

Third, control in terms of project guidance is earned in any open source projects with any sort of following. It doesn't matter if you're the original developer with the initial idea; if the community is willing to follow your guidance, they will. If not, they'll simply not participate.

Enough soapbox. In terms of project management, divide the role into two functions: 1) Getting developers involved, taking on tasks, code reviews, guidance and direction, etc. Trust me, this is as much a sales job as it is credibility-based. Top-down, hierarchical, seniority-based I-was-here-first type of expectations is a sure-fire way to drive volunteers away from your project. 2) Repository logistics. In the end, you can control who are/are-not committers, their permissions, etc. If you do #1 well enough, this will take care of itself.

As a last bit of commentary, open source projects are not easy to get off the ground. There are more projects than people willing to put forth the amount of sustained effort necessary to give your project legs.

Good luck!

Well, Captain Bligh, it all depends on how you hand out commit permission, now, doesn't it? If you make the source open, but tightly control commits, then the vision is all yours. Assuming, of course, that you can find anyone else who cares enough to submit patches for your review and evaluation.

Linus Torvalds had a great speech on google talk about how he is using (among other topics) git to avoid having to include all code from the open source community! It is deffently worth checking out!

You probably can't have your cake and eat it too. If you open your source under a "real" open source license, then anyone who wants to would be able to start their own project. You could maintain control of the "real" project. Then it is a matter of waiting and seeing which version users like better, and which version attracts most of the community. You will always have control of "your" branch of the project. What you must accept is that someone else may become more successful with your original code than you are, and thus also have control.

In general, there are more ideas out there than there are developers waiting to work on them. So your real problem will likely be getting anyone to care about your project enough to contribute patches, let alone care enough to usurp control.

Even if you make the source available in a repository for anyone to grab, you still maintain control over the repository: you decide who has access, you decide which patches are committed (or at least, you decide who gets to decide which patches are committed).

However, this doesn't stop people forking your project and taking their forks in a different direction. There aren't any easy ways to prevent that: some people are ornery and will fork every project they touch, while other people might just have a different idea about how your code could be useful.

The best way to minimise forks is to be engaged with the community: be involved in discussions on the direction of the project, accept patches that add features that people want (while maintaining your own coding style and standards of course). If it's easier for people to work with the community and you than it would be to maintain their own fork, most people won't bother forking.

Of course, this means you've ceded some control to the community, because if you stubbornly refuse to give them what they want they're going to make a fork..

Sounds like the missing ingredient is some enthusiastic developers who love your ideas and are prepared to work for free.

I don't think they just pop out of the internet; you will need to go find them.

And once you find them, you need to keep them interested, which may well mean giving up some or all of that control...

Ask yourself what is your goal here–to deliver a software innovation to the world, or to have a pet project?

Well it just depends on what kind of project you are opensourcing.

Are you opensourcing one tightly defined core functionality in a small library, like a Ruby Gem, or a PHP PEAR Package, or are you looking to create the next Wordpress where millions of users have an opinion?

I would suggest starting small. Use something that you've written before, and can be used by others:

A jQuery plugin.
A Wordpress Plugin.
A PHP PEAR Package or a proposal to the Zend Framework.
A Ruby Gem that creates a behavior that can be used in Rails.
A module, or add on to some open source CMS.

Create a specific functionality that you want. Put it somewhere that other users can fork or branch your code, but don't let them merge back to the main branch or trunk of your code.

That way people can work with your code, but ultimately, you have control of what goes back into the official project.

Basically, you can't.

You can't prevent someone else fork your code and start a new project.

At most what you can do is to pick a license that says the source code can't be used to the same product ( I don't know which license is this, but it exists )

And secondly, what you can do is to have a very good control of existing base and a list a features you want to include.

If your project is forked, your new features will make less attractive the other.

Finally, your project will be forked if you don't work on it and leave it die. Otherwise nobody will come and fork your project when you're doing all the hard work right?

Here's a couple of interesting videos on the subject:

http://www.youtube.com/watch?v=-F-3E8pyjFo

http://www.youtube.com/watch?v=0SARbwvhupQ

If it's open source, at the end of the day you cannot control it - anyone will be free to fork it and go on their own sweet way. The way to prevent this happening is to be a "benevolent tyrant" and take on board other people's views on the project's direction. This assumes anyone else is interested in what you are doing, of course.