|
|
|
| Authored by: Gringo_ on Friday, April 20 2012 @ 11:28 AM EDT |
I am one who develops APIs. On my web site, I sell a
library, with its
attendant API, to facilitate access and
control of a specific kind of
peripheral device.
In designing the API, I wanted whatever would be the
most
convenient for the developer using my API. I wanted it to
have a certain
internal logic and consistency such that the
developer could almost guess,
without even consulting the
documentation, how he would go about some part of
the
implementation. This we call "intuitive design". I wanted
the developer to
have easy access to all features of the
peripheral device. In the end, the hope
was that for the
developer, the use of my API would be so easy as to allow
him
to focus on what he wants to achieve via use of the
peripheral, rather then
worry about implementation details.
Where did the inspiration for my
API design come from? It
came from many years of using other people's APIs for
other
things, and learning what worked well for me and what
didn't. There are
also many conventions one learns
developing software, and following these
conventions is what
contributes to "intuitive design". Then the more I imitated
those who went before, the more intuitive my design would
be.
In a
way, we want the API design to be as
uncreative as possible. We don't
want any surprises
for the user. We want the API design to be what he would
expect.
If we assigned a group of programmers to discuss among
themselves how the API should be designed, each would
contribute from their
knowledge and together they would
slowly converge on the Platonic ideal of how
it should be,
as if it already exists in some other dimension and it is
our
job to discern it. Each class or method name would be
chosen to have as little
creativity as possible, by being
the most accurate description of the operation
the method
carry's out.
In fact, if we were to compare an API design to
a work of
literature, we would compare it to the most uninspired
literate we
can imagine - formula-written pulp fiction. In
the end, an API wouldn't have
anywhere near the range of
expression found in a pulp fiction novel. It would
be more
like a phone book or a map.
In the end, then, good API design
is exactly the
antithesis of creativeness. We don't want it to be creative
at
all.
Should it deserve a copyright? Lately I have been
thinking of my
own library that I sell on my web site, where
it is fully documented. How would
I feel if somebody copied
my API, but implemented their own libraries? I think
I would
feel flattered that they recognized the logic in my design.
If they
want to use the same design, more power to them. The
main bulk of all my effort
was developing the implementation
- my library. This required my special
knowledge of the
subject area, a knowledge few possess. Let them go ahead and
try to do an implementation as efficient and reliable as
mine! [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 12:04 PM EDT |
The "blueprint" analogy that is often mentioned is actually rather
apt.
Designing a good house where everything is laid out optimally and which
supports all the needs of a family as it grows and changes over a long
period of time is very analogous to designing a good API.
So the question is whether the design of a house is protected by
copyright independent of an actual blueprint document. If an architect
comes up with a great house design and I make my own house to the
same specifications, taking advantage of all the architect's hard work but
without actually copying his blueprints, is that a copyright violation just
because designing the house was a lot of hard work?[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 01:42 PM EDT |
Thinking of so many things at once... does not mean it is unique (in an IP
sense)!
Tinkering.
An author of a fictional work also has to keep all the ducks in a row relating
to the plot. As the plot thickens, then foundation needs to have been formed
prior regarding characters etc.
General stuff, these APIs usually are, it is, in the end the exact twists and
turns of the plot as it executes that becomes the store. The rest, just a list,
of value only when they are woven into the story.
So, could someone else use the same names - yes they can, but can. There is a
limit to the names one can use (is finite), so granting a monopoly on such a
list would prevent anyone else from using the same names, for an independently
developed story, with it's own way to get it's own story told.
In reality, there is no really new story, only old stories, told going back
thousands of years, dating from the time when they were repeated again and again
around campfires, at a different time. They can be classified as comedy, or
tragedy (per the Greeks). So, to grant monopoly on APIs as a list of
characters in a story, is doing an injustice to future writers of fiction....
and would prevent a better story from being told (especially since, due to the
lobby of folks like Disney CORP, who would like a perpetual monopoly over their
use of certain stories, etc... we now have over 100 years for protection of
copyright).
For any court to award protection to API's - well, should not ever happen. I
thought that we were finished with that type of thought, where it ended with the
famous "look and feel" lawsuit between Apple and Microsoft.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 05:48 PM EDT |
APIs are hard to design because most people think your argument. The best
APIs are ones which are simple, direct, makes the code read like English (for
English speakers), and makes little to no assumptions about its use which
become part of the specification. It should only do its job and do it very well
with minimal dependencies.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, April 20 2012 @ 09:06 PM EDT |
I don't understand why everyone is focusing so much on creativity. As an
analogy, coming up with a proof of a long standing mathematical conjecture may
require a lot of creativity, but that does not make the proof copyrightable.[ Reply to This | Parent | # ]
|
|
|
|
|
