views:

140

answers:

3

Recently, we've release first stable version of our API access for developers(main features of main product).

Our API now has about 4 features with their own signatures, response types and so on.

To increase its popularity we want to release Wrapper Class for this functions in the most popular programming languages.

So now we have to decide, how and where this Classes will be hosted:

1) Should we use some public repository(github, Google Code etc.) - so anyone who want to enhance it will have the this possibility(I doubt that we can find many).

2) Or should we just make an archives available for download through our site, and maybe release them to the most popular class repositories(code snippets)?

What benefits/drawbacks do you see in each of this approaches? What should we choose?

Important issue #1:

We have an ability and resources to implement this classes with decent code quality in few languages.

Important issue #2:

We will have more modifications in our API signatures - so this classes has to be reworked too.

Important issue #3:

Good code quality and documentation is a must.

+2  A: 

I thoroughly recommend releasing the code to the community; additionally I think it'd be a good idea to release it using a public repo. Even if you don't have many users contributing (though I suspect you are probably underestimating that), the fact that you've released the code will be a draw for many developers.

Using a public repo demonstrates transparency, openness and a willingness to engage with developers, all things that will be appreciated.

On top of that often people are put off by 3rd-party binary blobs since bugs cannot be fixed; releasing the code will have very real practical uses for your end users.

Keeping in mind you're targeting developers I think releasing code is overall a win.

Make sure you choose your license appropriately however, as developers may have issues with certain licenses. Something like the MIT license pretty much covers all bases - i.e. developers can use it commercially, do whatever they want with it as long as they realise you're not liable for issues coming out of it.

Go for it!

kronoz
+2  A: 

It really depends. As kronoz already set the license is most important at first. That will enable other users or not. Then it depends what do you expect from making it open source. If no know what "open" really means than it is super to do.

  • There maybe will be people chiming in and develop your code.
  • Don't expect to raise code quality
  • Always be aware that a community develops it own sense where the development should lead to. If this differs from your goals than you gain not that much because you will have to fork off again
  • You need a mediator in the community. Someone that reads the mailing list, answers questions, describes things. Only then you get the maximum out of this cooperation
  • Other developers bring in other views and that is most of time really valuable
Norbert Hartl
+1  A: 

I'm having a bit of trouble understanding your question.

First off, if you are planning on making your API wrappers OpenSource but not the code they wrap, then you will have to be very careful about how your OpenSource license is worded. Also, you should think about whether you want to allow clients to use your API in non-OpenSource programs. You could perhaps allow both using GPL with a linking exemption. The linking expemption is important though.

I have released quite a few API's as Free Software myself, so perhaps I can address the rest.

Very, very few people will do anything more than just use your API. A few folks will write back with suggestions. A very few will actually look through the code. If you get someone who actually wants to submit patches, you have found a rare diamond. Cherish it.

That doesn't mean you can't insist on certian standards of code quality and style conformance. But be encouraging.

T.E.D.