Announcing the development of LIBSTOCK - Your place for code

[drdoug]

I think as multiple compiler projects is OK as long as there is clear labeling of what the projects are. Perhaps use logos that are very easy to read.
I think it would be helpful to have some selective searching similar to what Mouser offers to help limit the parameters.

Sorry mE I hope this section doesn't get clogged with everyone's individual ideas but I hope you can sort through the noise. I think a community like this is well suited toward your strengths and would help a lot of people (and hopefully your bottom line).

[janni]

...can I suggest you build in a means to identify duplicate or very similar items and how well tested (maybe a score 1-5 or stars or number of registered users that have used it or something) and how functional and correct any code is.

That may be hard to implement if you mean some experienced people going though projects to spot similarities or duplicates or to evalute projects . On the other hand, a mechanism to vote on projects would surely be appreciated by all.

Certainly, library/project users' feedback is very important - not only to evaluate the resource, but also to facilitate the process of improving it and to help other users that have trouble with implementation. I hope it will be possible for users to post their opinions and suggestions, as well as point to spotted problems or help other, less experienced users (note, that the author may be long gone from LIBSTOCK, while his projects may still be in use).

[anikolic]

A further thought. A section for listing external resources.

Interesting idea. Although we already did much of the design, we can make a simple global collection of link contributions, if that can help. There can also be a box with top 10 websites that community votes most for.

I think you should actively NOT allow projects in other compilers however.

Well, we didn't want to disallow people to share knowledge. We will prefer our compilers, and leave the categories "other" for everyting that is not mikroC, mikroBasic and mikroPascal. Maybe some of those people decide to switch over to mikroElektronika compilers, when they realize how great community we have.

I think as multiple compiler projects is OK as long as there is clear labeling of what the projects are. Perhaps use logos that are very easy to read.

We had an idea to have this represented with icons, but we ended up having a good looking and clear solution with just simple textual representation of compilers, architectures and other. Take a look at a preliminary design (work in progress).

LibStock_categories_preliminary.jpg

I hope it will be possible for users to post their opinions and suggestions, as well as point to spotted problems or help other, less experienced users

Yes, janni, we also had this in mind. It's very important that community actively encourages and supports the projects and contributors that are good. We will have mechanisms for this "natural selection" of good projects, and we will also have a mechanism for developers to accept suggestions and improve their code.

Best regards,
Aleksandar

[Vladimir_C]

Great idea!
Today, many projects use color TFT modules, unfortunately MikroE has support only one controller, you must make a separate section where you can place the library for different controllers TFT modules, and many people will buy these libraries for their projects .....
Due to the absence of these libraries I have to use the MPLAB .....

[Mince-n-Tatties]

Looking forward to this.

is this for library code only or is it for library code and general projects.
will it be forum presented as split across the compiler versions and targets, or will it be one big bucket like the horrid active topics?

not sure if i like the idea of it being a dumping zone for spurious chunks of non-mikroE compiler code. I also feel this would result in lowering the general interest from users for the reasons already given “why does this code not compile”.

I do however feel there is a place for collecting examples of “how-to-do-it” code which people may have already created for other compilers in the past (including ASM). So that it is all under one roof, but it should perhaps be another forum branch (misc).

Who will be responsible for a library code block which is sold via mikroE, which results in some end user product going on fire / electrocuting / burning / turning something off (someone’s fridge) which should be on etc etc.

Are there T’s & C’s available for reading?

Will mikroE do any official evaluation of library files?

There is a world of difference between giving something away for free with the global "not my fault what it does or how you use it" disclaimer, compared to the global (remember this website can be read world-wide with any code examples being available for download world-wide) legal constraints for a service which is charged for. A simple example would be exporting/importing anything with encryption is forbidden in some countries. Perhaps the whole legal side can be covered by a disclaimer at point of entry to the website so that everyone is protected.

[drdoug]

Good points Mince.

[janni]

Who will be responsible for a library code block which is sold via mikroE, which results in some end user product going on fire / electrocuting / burning / turning something off (someone’s fridge) which should be on etc etc.

You probably never have had the time to read mE compilers' disclaimer, Mince .

Hardly any software nowadays is sold with full-responsibility warranty. That happens only (and rarely) with custom software. Situation is different for software being part of a final (hardware) product where the warranty covers the whole product which has to fulfill specific requirements (like safety).

There is a world of difference between giving something away for free with the global "not my fault what it does or how you use it" disclaimer, compared to the global (remember this website can be read world-wide with any code examples being available for download world-wide) legal constraints for a service which is charged for.

I don't think there's any real problem here. First, we're not talking about thousands of $ per product here, more like few bucks recompense to make code authors' effort worthwhile. Second, any problems with charged services may only arise if what one buys differs from what one was promised. That's hardly a problem with small chunks of software intended for (mostly) hobbysts.

A simple example would be exporting/importing anything with encryption is forbidden in some countries.

Such countries have no power to prosecute the suppliers - unless they operate directly in these countries. Different situation is with countries that forbid transfer of certain technologies (like advanced encryption techniques) to some other countries. Persecuting own companies is, naturally, possible . Even if Serbia is bound by some international treaties to protect such technologies, somehow I don't see anybody willing to offer highly advanced encryption algorithms for little financial gain.

[Mince-n-Tatties]

Who will be responsible for a library code block which is sold via mikroE, which results in some end user product going on fire / electrocuting / burning / turning something off (someone’s fridge) which should be on etc etc.

You probably never have had the time to read mE compilers' disclaimer, Mince .

Hardly any software nowadays is sold with full-responsibility warranty. That happens only (and rarely) with custom software. Situation is different for software being part of a final (hardware) product where the warranty covers the whole product which has to fulfill specific requirements (like safety).

There is a world of difference between giving something away for free with the global "not my fault what it does or how you use it" disclaimer, compared to the global (remember this website can be read world-wide with any code examples being available for download world-wide) legal constraints for a service which is charged for.

I don't think there's any real problem here. First, we're not talking about thousands of $ per product here, more like few bucks recompense to make code authors' effort worthwhile. Second, any problems with charged services may only arise if what one buys differs from what one was promised. That's hardly a problem with small chunks of software intended for (mostly) hobbysts.

A simple example would be exporting/importing anything with encryption is forbidden in some countries.

Such countries have no power to prosecute the suppliers - unless they operate directly in these countries. Different situation is with countries that forbid transfer of certain technologies (like advanced encryption techniques) to some other countries. Persecuting own companies is, naturally, possible . Even if Serbia is bound by some international treaties to protect such technologies, somehow I don't see anybody willing to offer highly advanced encryption algorithms for little financial gain.

I do not (because i cannot) use mikroC for commercial products, so for me the concern is simply that mikroE and the contributors are protected so that we are all able to enjoy the community which has grown around us. Where Serbia sits may not be the issue as the “contract” would most likely exist between library developer and purchaser

You may have taken my single example too literally as being the one to think about.

You do raise a good point, which I may have missed… if the target is “hobbyist” then I was aiming too high.

[janni]

I did not intend to discard your concern, Mince, just alleviate it by setting the right proportions.

Where Serbia sits may not be the issue as the “contract” would most likely exist between library developer and purchaser

Any intermediary in a transaction is also bound by law, if such exists, but, in my opinion, there doesn't seem to be any serious risk involved. There are plenty of places on the net serving as a go-between in software trading, but no stories of their legal problems (though I suspect, that a cursory check is made whether the software sold is what it is claimed to be). It's the money transfer and tax laws that require attention of such companies, rather than passing the software. As for developers safety, as long as they act in good will, they're in no real danger.

You may have taken my single example too literally as being the one to think about.

I may have had trouble imagining any other that could potentially cause problems . We could, naturally, assume that somebody may act with evil intent trying to sell worthless piece of code and prepare for it, though I don't see anybody from our little community doing it on purpose. And I suspect people will think twice before buying code developed by somebody unknown, for however low price.

Anyway, my guess is that mE will not hurry with introducing the sales and this part of Libstock will stay small and fully controllable.

[Mince-n-Tatties]

We could, naturally, assume that somebody may act with evil intent trying to sell worthless piece of code

i would not naturally assume this of anyone; i would be more likely to consider a scenario in which an unexpected outcome resulted in end unit failure.

but yes you are also correct in the intent of some people, as i have just remembered over the years having seen people join this site simply to moan about the products where i later realised these people to be very active in other forums for other products (readers can make their own mind up over what these people where trying to achieve).

On that note i was very very impressed to have recently read a reply in a thread by a mikroE person where it was made very clear that mikroE would not entertain creating a list of why anyone should purchase mikroE products over any other competition. This displays integrity in individuals and confidence in their product portfolio which forms in part why I have always been eager to support mikroE.

[janni]

I can only agree with all you've written, Mince .

Back to the shape of Libstock, I like the selection tools promised by the presented screenshot and the idea of User Requests part .

Some suggestions that came to my mind:

- some kind of ground rules (and possibly help) for developers should be added (if not already there),
- general T's & C's, mentioned by Mince for paid transactions, should have their clearly visible link when such transactions became possible,
- Code Categories could have subcategories making search for specific projects easier (projects' tree will probably evolve with time, anyway),
- Code Categories could contain 'System Libraries' item (kind of personal request at the moment ),
- project version number may not be informative enough - 'last updated' position could be sometimes more helpful.

We are considering to implement some sort of credits as a virtual money, for security reasons.
Do you consider this approach good?

Makes perfect sense, especially for those of the contributors that would like to spend their earned credits on mE products. Instead of transferring money to and fro, mE could then just send ordered items. Also, conversion to real money could be limited to cases of direct request by the contributor.
Another security step could be a delay in money transfer, to leave time for complaints and money-return claims. It could be a natural process, as the norm is to wait for some minimal amount of money justifying it's transfer as well as limiting number of transfers to, for example, one per month.

[RoMSI75]

Makes perfect sense, especially for those of the contributors that would like to spend their earned credits on mE products.

Then I would start doing library that will draw flowers on graphics LCD on mP/microchip products to earn some credit to have it when mE will decide to sell source code of some of the libraries embedded in mP. Or I will make some projects for students (I saw some requests on forum ) in order to have enough credit. Do you think it will be possible? My life will be safer!
Things are getting complicated. A lot good suggestions but also a lot of dreams. This LibStock is a big challenge for mE. Also, it is a good thing to create environment for sharing idea and also got something in return, not only eternal graceful. I wish them only luck.

All the best,
MSI

[Mince-n-Tatties]

credits should be available to people that provide useful (as decided by the users/mE staff through star rating voting etc) tools for free, not just applied as a credit scheme for those that charge for their output.

[RoMSI75]

credits should be available to people that provide useful (as decided by the users/mE staff through star rating voting etc) tools for free, not just applied as a credit scheme for those that charge for their output.

As far as I understood , that "credits" are "real money" charged by mE with they paying system for code that WE made (and buy by somebody) and those money will be converted in credit for buying stuff from mE, that is also a good think. We build software/tools for developing with mE compiler (mE sell compilers not libraries) and with those money it will provide software/hardware tools for developers that sell code (with sources or only compiled) for developing more and more.

This is a good way for everybody to be happy. There are 3 types of people: 1: (my friend, an open-source fun), that have passion for programming and offer to everybody for free his work providing source code for modules (but not for all project), 2: (my boss) that have passion for money and sell everything and 3: (me ) that have passion for programming and want to sell something.

I think in this forum are some of first type and most of third type (and some of second - mE sales team ).
This "credit" way of selling is a way to encourage developers to make code that will work with mE compilers. mE found a way to sell their products to developers - tools to develop more. In this way, mE community will grow and this is good for all of us.

All the best,
MSI

PS: I like the way that microchip use to deal with libraries: offer source code and let you do whatever you like (use, modify ...) with sole condition: use it on microchip products. This should be the same philosophy behind mE for libraries: do whatever you want as long as you will compile/recompile with mE compilers.

[stevenindon]

Hi all,

PS: I like the way that microchip use to deal with libraries: offer source code and let you do whatever you like (use, modify ...) with sole condition: use it on microchip products. This should be the same philosophy behind mE for libraries: do whatever you want as long as you will compile/recompile with mE compilers.

Kind of like this idea.. anyway the user libraries should be a "Use at yr own risk"... as we should NOT trouble mikroe too much. Anyway it has to be loose enough for people to put up their libraries and other to help improving it.

Cant wait for it to be up and running.